The New York Timesのエンジニアリングチームが、2018年11月の米国中期選挙でのトラフィック増加を背景とした、 スケーリングとインシデント管理への取り組みについての記事を書いている。
2018年11月の米国中間選挙に伴うアクセス増加に備えていた同チームは，2016年からほぼ倍増したデジタル加入者による，モバイルおよびデスクトッププラットフォームのトラフィック増に対応する必要に迫られていた。そして2017年に，オンプレミスのインフラストラクチャからクラウドへの移行を含む，プラットフォームの再設計を実施したのだ。これによってインフラストラクチャとインシデント管理が分散化され，各チームがそれぞれ責任を負うようになったが，依然としてチーム間の依存関係の管理が必要であった。
プラットフォームの大きな課題は、結果をリアルタイムで確実に提供することと、インシデント処理を異なるチーム間で調整できるようにすることだった。この課題に対してチームは，まずアーキテクチャと運用をレビューし，ストレステストを実施して，さまざまなチーム間のコラボレーションを確実にするための監視グループを特別に用意するという，多段階のプロセスで取り組んだ。InfoQは今回，The New York TimesのエンジニアリングディレクタでデリバリエンジニアリングとSREを担当するPrashanth Sanagavarapu氏と，同じくデリバリエンジニアリングとSREを担当するプリンシパルプログラムマネージャのVinessa Wan氏から，プロセスの詳細について話を聞くことができた。
まず最初に，"我々SREと企業内ステークホルダやエンジニアリングチームとの仲介者"として行動する"中間総選挙リーダシップチーム"が組織された。The New York TimesにおけるSREモデルの運用について，Sanagavarapu，Wan両氏は次のように説明する。
デリバリエンジニアリンググループには、専任のSREグループがあります。デリバリエンジニアリングとは、ツールとオートメーションを構築し、プロセスを定義し、それらの取り組みを通じてチームと提携することにより、製品エンジニアリングチームのビジネス速度を向上させることを目的とする活動です。SREチームは、より大きなプロジェクトや目標のためのエンゲージメントモデルを使用してチームと連携すると同時に，生産準備レビュー(Production Readiness Review, PRP)やチームの教育の活用を通じて，チームに対する継続的な指導も行っています。
アーキテクチャレビューにより、個々のチームが監視やシステム停止からの回復にどの程度対応しているかが明らかになった。同社の監視スタックは、クラウドサービスプロバイダの管理するツールと、 PrometheusやGrafanaのような自己管理ツールを組み合わせたもので，警告を行うためのEメールやSlackと統合されている。Sanagavarapu氏とWan氏は、監視の方針と設定の概要を次のように説明してくれた。
デリバリーエンジニアリングチームは、プロジェクトの作成時に，パブリッククラウドプロバイダの提供するツールを使用した基本的な既定の監視機能をアプリケーションにセットするためのガイダンスと自動化機構を提供しています。当社のアプリケーション開発チームは、SLOとSLIを設定して，サービスの信頼性と品質を監視しています。アプリケーションの管理はこの監視と警告によって行います。信頼性情報を共有するために集中化された視覚化ツールの開発も行っていますが，チームはそれぞれ，共通メトリクスと自身のシステムに固有のメトリクスとを併用しています。
システムが高いトラフィックにどの程度耐えられるかをテストするため，チームは同社の運用環境でテストを実行して，必要に応じてテストを停止できるような状態で，実際のトラフィック増加を常時監視した。このような負荷テストのアプローチでは、着信トラフィックを複製するシャドウトラフィックの生成を備えた上で、運用システム環境に対して実行するのが一般的な方法である。The New York Timesがクラウドに移行した後、同社は自社サービスに自動スケーリングを利用したのだろうか？Sanagavarapu氏とWan氏が説明する。
記事が急速に広まったり，ニュース速報イベントが発生した時などは，スケールアップのニーズが一気に高まります。当社のシステムには自動スケーリングがありますが、それには限界があります。現在は，予想されるトラフィックよりもシステムを少し大きく拡張するようなプロビジョニングを実施しています。さらに、実績から学んだ共通的なトラフィックパターンを使って，事前にシステムを拡張することも行っています。
準備状況評価(readiness assessment)に基づいて，技術スタックと依存関係によってグループ化されたチームは，会議室を抜け出して，ビデオやメッセージングツールを介して対話しながら作業を行う。チーム間の依存関係は，"内部API依存関係と外部クラウドプロバイダサービス"である。前者の依存関係は"エンドユーザエクスペリエンスあるいはビジネスワークフローによって定義されている"，と両氏は説明する。既知の依存関係を持つチームをグループにすることで，ビジネスワークフローのエンドツーエンドの信頼性テスト，ユーザエクスペリエンス，最終的には増加するトラフィックの処理も可能になっている。