Blog
ブログ

「オペレーションルームに歩いて行く – もうこれ以上何もする必要はないと思う」

開発者のための最新の機能のリリース（訳注：英語サイトに飛びます）で、PagerDutyのシニアエンジニアDavid Yang氏と私は、私たちの内部アーキテクチャが単一のモノリシックなコードベースから数十のマイクロサービスの組み合わせにまで進化していくのを見てきました。

彼は、8000人以上のPagerDutyの全顧客にアラート通知を送信するサービスを所管するIncident Management – Peopleチームのテクニカルリーダーです。私たちは座って、彼らのサービスの運用について彼のチームがオーナーになるよう切り替えた後の生活について話しました。 私たちが見た利点と欠点に関するいくつかの観察を紹介します。

今はチームがサービスのオーナーになっています

開発者がサービスのオーナーになるモデルに移行して以来、開発者の独立性はますます高まっています。副作用は、インフラストラクチャのプロビジョニングと管理の難しさを最小限に抑えられたことです。現在、チームは邪魔と障害を最小化するように最適化したいと考えています。 インフラをサポートするチームは、人間の介入の必要性を最小限に抑えるために優れたセルフサービスツールを提供することに重点を置いています。

開発者がコードのオーナーになると、サイクルタイム、つまり「これは問題だ」というメッセージがどこかで表示されてから実際に問題を解決するまでの時間が短縮されます。これは非常に価値があります。

文化面での変化は

人々がより多くのコードのオーナーになり、自分たちが運営するシステムのために一般的にはより多くの責任を負うようになると、道を邪魔するものを排除することを重視する文化が広がります。各チームは、 「自分が今まで、あるいは将来ブロックされていないことを確認するにはどうするか」という考え方に向かって最適化されます。ブロックされるともっとはっきり分かります。以前は、ホストをプロビジョニングするたびに私は毎回運用チームに問い合わせなければなりませんでした。 私のチームは他のチームの障害物で隠されていないため、自分たちの障害物をよりはっきり見ることができます。

私たちには、エンドツーエンドの顧客価値を提供するプロセスのすべてを所有することに重点を置いたチームがあります。これは非常に貴重です。

インシデント対応プロセスではどうに役立つ?

サービスのオーナーシップの境界が明確になっています。運用の問題が発生した場合に、影響を受けるチームを簡単に特定できます。そして、自分が従うべき正しい手順、例えばそれは「これがそのチェックリストです」という客観的な手順ですが、それを知っているということが大事です。 これによって問題の解決に100％集中し、インシデント前後のコミュニケーションに集中することができます。

それほどうまくいかなかったことも

サービスのオーナーになっていても、そのサービスに問題が発生しないとは限りません。当社のサービスの運用維持に専念するためには、そのためだけに使う時間が必要です。 これが結局はチームの時間の多くを占めます。特に知識のギャップがあるレガシーサービスで問題になります。 当初は、私たちのスプリントでの作業性を守るために十分なガードレールを設置していませんでした。 これは客観的な意思決定を可能にするためにKPI（特定のスケーリング目標や運用負荷レベルなど）を活用することで改善されています。

将来は?

[業務関連のワークロードと機能開発ワークのバランスをとるため]各チームは、メトリックによって客観的な意思決定を推進するために、次のように問い続けています。「私はこうした道具を日常的にどう活用していますか？ どのようにして客観的な意思決定を行うのですか？」と。

組織内の業務の中で変更を実行しようとすると、多くのコラボレーションが必要になります。 適切なメトリックが何であるかを把握し、それらのメトリックについて議論することも必要です。

技術的負債（technical debt）が借金のようなものだったら、手作業でチェックインしない限り、それを追跡するのは難しいでしょう。 多くの人にとっては自分の当座預金口座に資金がなくなったことを知る唯一の方法は、口座の残高を確認することです。さらに悪くなると、小切手が返されたり、デビットカードが拒否されます。

しかし、技術的負債の測定はもっと自動化できます。 これは、お客様の銀行口座とは違って、ITインフラストラクチャの場合はそれを専用のツールで継続的に監視でき、重要なヘルスメトリックについて通知を受けることができるからです。 次に、監視データを使い技術的負債についての情報を得ることができます。 つまり、データセンターで問題が発生したときに手動で監査する必要はありません。 問題があることを知るのに、サーバーがダウンするまで待つ必要はありません。 インシデント管理ツールは、その情報を提供します。 エクステンションを使えば手作業で面倒なことを測定することなく、技術的負債を取り込む方法も提供しています。

インシデント管理は、技術的負債を追跡して修正するのに役立ちます。追加の投資は必要ありません。

技術的負債の定義

まず、技術的負債の意味を説明しましょう。 技術的負債とは、長期的には非効率性やその他の問題を引き起こすような、ソフトウェアコードやアーキテクチャの不完全性を指します。 たとえ欠陥自体が小さいとしても、その効果が継続的に繰り返されるため、時間の経過とともに多くの利子が生じることがあります。

例えば、モジュラーアプローチを採用しておらず、同じ機能の複数のバージョンをコードに含むようなプログラムは、より優れたプログラムよりも実行に数ミリ秒余計にかかることがあります。 一度だけそれを実行するなら、大きな問題にはなりません。 しかし、それがサーバーの側で1日に数千回実行されるWebアプリケーションであれば、パフォーマンスが低下したり、CPU時間が浪費されたりするという負債があっという間に積み上がります。

技術的負債には多くの潜在的な原因（訳注：クリックすると英語版のWikiに飛びます）があります。 場合によっては、例えば何かを迅速に導入しなければならず、ベストプラクティスに従う時間がない場合は、負債がコストに見合う価値があると判断（少なくともその時点で）して、技術的負債を意図的に負うことがあります。管理者の中で最も優れた人でも将来の技術的負債を避けることは難しいです。 将来を見通せない限りは（例えば、あなたがアップグレードする余裕がないために今日も使用している10年前のスイッチが、最新のファイアウォールツールではうまく機能しないということは過去の時点では分からなかったはずです）。 その場合、技術的負債は、不完全な世界での生活で起きることまったく同じ経緯をたどります。

技術的負債を追跡する

技術的負債には多くの源がありますが、それをインシデント管理を使用して測定するというアプローチは、問題の原因を問わず問題の追跡を容易にします。繰り返しますが、時間のかかる手動のシステム監査で非効率性を検索する代わりに、インシデント管理データを技術的な負債の程度を評価し、それを評価するためのプロキシとして活用できます。

やり方を理解するために、PagerDutyが追跡するさまざまな種類のインシデント管理データの例と、それらのデータが技術的負債について明らかにできることをいくつか見てみましょう。

まず、ツールが生成するアラートの生の数を取得します。これは非常に基本的な指標であり、さまざまな要因によって影響を受ける可能性があります。しかし、インシデント管理の報告システムが適切に構成されており、インフラストラクチャに大きな変更を加えなくてよいと仮定すると、技術的負債の規模とツールが報告するインシデントの数との間に相関が見られる可能性があります。負債が増えるとパフォーマンスが低下し、応答時間やリソースレベルが特定のしきい値に達するとアラートがトリガーされるためです。したがってアラートの発生率が月ごとに減っていれば、コードがより効率的になったので技術的負債が減っている可能性があります。

平均解決時間（MTTR）は、技術的負債を見るためのインシデント管理の指標です。MTTRが悪い一般的な原因の1つは、コードがあまりにも複雑すぎることです。例えば、上の例を再利用するために、急いで書かれたコードには冗長な機能が含まれているため、管理者にはすぐに理解するのが難しいでしょう。これは、事件に対応するためにコードを読み込んで変更する必要がある場合に、解決時間が長くなることを意味します。

技術的負債の源を見つける

インシデント管理データは、技術的な負債に関する一般的な傾向を追跡するのに役立つだけでなく、問題の原因をゼロにするのにも便利です。

たとえば、特定のプログラムに関連するインシデントのMTTRが平均MTTRよりも高い場合、問題のプログラムが技術的な負債を生成している可能性があります。同様に、あるタイプのオペレーティングシステムを実行しているサーバーが不均衡なアラート数の大部分を占めている場合、おそらくコードまたは構成上の欠陥があります。それはあなたが対処できる技術的な負債です。

インシデント管理データを使って技術的負債を特定し、対処するのはとてもクールで、ほとんど追加作業を必要としません。あなたは既にPagerDutyのような操作と報告を集中化するハブ（うまく設定すればですが）を備えた監視システムを備えています。これらのリソースを活用して技術的負債を見つけて修正するには、追加のツールや投資を必要としません。既存のソフトウェアを使用して、コードや操作をより効率的にすることができます。

DevOpsの失敗は微妙な話題です。それが一般的にはDevOpsは障害を回避する方法として認識されているからです。その結果、DevOpsの実践に失敗した場合、状況はほとんど絶望的に見えます。しかし、フェイルファーストのビジネスアプローチや、「失敗して早く修正する」アジャイルの手法がしばしば証明するように、DevOpsの失敗は実は正しい方向への一歩なのです。失敗から学び、DevOpsの実践を、後まわしではなく早く、より大きな成功に導く道に向かわせるための第一歩です。

DevOpsはアジャイルに発するものです。頻繁なフィードバックループで開発サイクルを短くすると、顧客のニーズに一層合致した製品の提供に集中できます。フィードバックループの活用ポイントは、顧客からのフィードバックを通じて行動から学び、何が正しいのか、何が改善できるのかを測定することです。

フィードバックループは、頻繁な変更と失敗からリスクを実際に減らすよう学べる機会を提供するため、効果的です。DevOpsの実践に打撃を与える失敗はいろいろなので、それにどう対応するかが重要です。ではいくつかを細かく見てみましょう。

インシデント対応の失敗

ソフトウェア関連の問題が発生した場合（ソフトの展開に関連することであろうとバグであろうと）、それが起きたという事実よりも、どう反応したかがたいていは重要になります。 ここでの失敗は、以下を含む複数の形で発生する可能性があります。

過剰反応**：障害からの回復や、失敗の繰り返しを避けるために、過度の時間を費やしたり、過度に多くのリソースを費やしたりすることです。

誤った反応**：情報の欠如による問題の誤診や、問題の見積もりを誤ること。

無反応**：問題を早急に修正したり、効果的に修正したりするのを忘れ、直後に問題が再発すること。

インシデント管理とKPIによる成功を評価することは、DevOpsの成功の要件である測定の重要な部分です。関連する情報を浮上させ、他のチームメンバーを募集し、個々のコンポーネント（およびそれらの背後にある人）を原因として示すのではなく、全体としてシステムを見て、インシデントを迅速に評価して解決します。

ここでの取り組みには、インシデント対応、知識の伝播、将来の問題を回避するための過去のインシデントからの学習、問題解決の自動化による迅速な対応といったことが含まれます。

プロセスの作り過ぎ

DevOpsは単なるプロセスまたはツールであると考えて、厳格で正式な一連の手順を設定することをに走る人もいます。しかし、あまりにも多くのプロセスを作ったり、プロセスについて厳格すぎたり、特定のツールセットを強制すると、組織の柔軟性が失われる可能性があります。 そうではなく、DevOpsには、組織の敏捷さを向上させるツールと手順が含まれている必要があります。

例えば、ソフトウェア開発と展開の効率の全体を測定するツールは、その効率を向上させるためのフィードバックを提供するのに役立ちます。 どうやって？ 変更が必要な箇所と削除する必要のあるボトルネックを指摘するのです。厳格になりすぎると、変化するユーザーベースまたは市場のニーズを改善または満たすために迅速に変えられなくなる場合があります。

DevOpsの範囲を制限する

DevOpsの実践の仕事は、組織内の一人の人間やチームだけには任せられません。 私は、既存のソフトウェア展開とメンテナンスの問題をすべて修正するためにある人が”DevOps Person”として特別に雇われ、”DevOps stuff”を魔法のように行う状況を目撃しました。しかし、そこには足りない点がありました、「そのアプローチが失敗する」と考えなかったことです。

同様に、顧客サービスおよびサポート担当者が、事前に知らされていなかった、週末にインストールされた新機能に関してコールを受けた状況も見てきました。 主なサポート担当者がお客様からソフトウェアの変更を知らされるような場合は、DevOpsの失敗が起きます。

DevOpsは、アジャイル開発から学んだことを取り入れ、ソフトウェアの展開全体を通じてエンドツーエンドで適用する、構成的な実践方法です。 これはビジネス全体の他の機能にも拡張する必要があります。 つまり、開発作業は各プロジェクトではなく顧客への価値に沿って行われ、製品チームはITスタッフとだけではなく、コールに対応する人や、技術文書を作成する人、アプリケーションを宣伝して販売する人、ビジネススポンサーとして働く人たちとも共に働かなくてはなりません。その中には将来計画を立案するエグゼクティブも含まれます。 フィードバックループを拡大して組織の全員を構成するには、誰もが覚えておくべきことがあります。

ここでは、フィードバックループ、コミュニケーション、および主要な測定活動を組織のすべての部分に拡大することを含みます。 また、サードパーティベンダー、サプライヤー、コンポーネントを除外しないでください。 外部コンポーネントの検証、監査、および監視も含めてください。

不毛な責任追及と競争を回避する

アジャイルは、組織のソフトウェア配信パイプラインでのボトルネックを明らかにすることが多く、物事を遅らせていると思われる人や活動を指摘するのは簡単です。これが起きると、DevOpsは意図していたのとは正反対に、チーム間をばらばらに引き裂くくさびを打ち込むことになってしまいます。

そうではなく、サイロ（真空中で仕事をしようとするチームや人）を取り除き、ボトルネックや改善を特定するよりも先にチーム間の壁を壊してください。 全員が最初に協力して責任を共有することで、チーム同士が競争する結果ではなく、１つにまとまるという改善ができます。

サイロを徹底的に排除する

組織内で例外を作っていることは珍しいことではありません。 たとえAgileやDevOpsで実際に成功を収めている組織でもあることです。おそらく、それはレガシーなアプリケーションや、過去に実績があるチーム、またはベテランの従業員です。 しかし、DevOpsの実践から個人やチームを除外するのは面倒な作業です。

サイロは、組織のソフトウェア展開の実践を複雑化して毒になる可能性があります。 そのサイロに共同創業者が含まれていたとしても、組織のDevOpsが奨励するプロセスとコラボレーションから免除されるべきではありません。 一言で言えば、DevOpsはサイロとボトルネックを取り除くことを意味します。例外なしに。

開発環境を無視する DevOpsは、本番環境と展開するもの以外にも適用されます。 アジャイル開発のスプリントが成功し、本番環境の導入が自動化され、テストが継続的に行われている場合でも、開発環境にこれらの実践を拡張しないと、独自の問題が発生します。たとえば、開発環境とテスト環境が同じツール、アプローチを使っておらず、その運用環境を管理する担当者によって管理されてもいない場合、ソフトウェアが想定外のユニークな構成に初めて遭遇したときに生産上の問題が発生します。

チームからのアクセスをむやみに増やさない DevOpsの結果としてチームワークが強化されるのは良いことです。またソフトウェアの開発過程で、新しい手順やコンポーネントにさらされるにつれ、チームメンバーが成長する能力も向上します。 しかし、これに伴う責任の追加分担を忘れると、重大な失敗につながる可能性があります。 たとえば、DevOpsはUI開発者がアプリケーションのデータベースに慣れるのに役立つかもしれませんが、UI開発者がDBの変更を自分で公開する権限を持つようになると、誤って本番データベースを変更するといった事態も起こるかもしれません。 ボトルネックは除去すするにしても、大災害を避けるためにコントロールも必要です。

重要なプロダクションシステムへの予期しないアクセスを監視して報告し、意図しない変更をロールバックする（またはロールフォワードする）手順を導入するべきです。

結論：つまりは人の問題です

ゴールはDevOps自体の成功ではありません。プロセスでも活動でもありません。ゴールはソフトウェアとカスタマーエクスペリエンスと組織を改善するためにDevOpsの使命をまっとうすることです。 これらのいずれかが欠落している場合は、DevOpsで成功していると思っても生きるのは難しくなるかもしれません。

これまで説明したことすべてに現実の人々を巻き込むよう肝に命じること、それが重要です。 DevOpsがどう役立つかに関係なく、失敗から学び、絶えず改善を続ける文化を吹き込み、顧客を幸せにし、楽しい時を過すことが本当に大切です。 あなた自身のゴールを達成するために働く毎日の中で、本当に大事なことを忘れないでください。

アラート 。それはいとも簡単に積み上がります 。一瞬で目にするアラートはほんの一握り。でも数時間、場合によっては数分後に、積みあがった山を見ることになります。 どのようにそれらを管理すれば、担当者がお手上げにならないようになるんでしょうか？

これらは非常に重要な質問です。 アラート管理システムにノイズが溢れていて、対応チームが慢性の疲労状態にある場合は、初動に対応するITアラート管理システムを持っていないも同然です。 過剰なノイズとアラート疲れは、アラート管理システムの有効性を完全に低下させます。

フィルタリングの適用：インシデントにアラートをまとめる

多くの点で、アラート管理システムの合理化の鍵は、関連するアラートをインシデントに統合し、インシデントの優先順位を決定するための迅速かつ正確な方法にあります。緊急度別にインシデントを並べ替えることで、ほとんどのノイズを自動でフィルタすることができ、すぐに注意が必要なものとしばらく様子を見ることができるものを、合理的に推量することができます。すべてのアラートがインシデント化や対応を必要とするわけではありません。対応不要なアラートを抑制すると、ノイズがさらに削減され、重要なことに集中できます。

ソート（優先度順に並べ替える）プロセスの一部を自動化する（例えば、ソースとキーワードで並べ替える）ことはおそらく可能ですが、一部の（多分相当な量の）ソートプロセスでは、ディスパッチャの役割を果たしているレスポンスチームの誰かが介在する必要があります。ただし、どのような方法を使用しても、基本となる基準は変わりません。

優先順付けのスキームのほとんどは、ITILが定めているインシデントの優先順位付けガイドラインなどに準拠しています。インシデントの優先順位は、インパクトと緊急性という2つの密接に関連する要因に基づいて付けられます。この記事では、これらの要因とその相互作用について詳しく見ていきます。

インシデントのインパクトを判断する

インパクトは、インシデントの影響範囲（部門、ユーザー、または主要サービスがどれだけ影響を受けるか）に基づきます。 影響判定プロセスの少なくともいくつかの要素を自動化するのは比較的簡単です。 たとえば、ほぼ同時に特定のサービスが利用できないことを示す多数のレポートが出てくれば、影響の大きいインシデントになる可能性があります。一方、単一のユーザーからの問題のレポートは、類似のレポートが他になければ、 影響の少ないインシデントだということを示します。 多くのIT部門にとって、インシデントの影響を判断するためのガイドラインは、次のようになります。

高インパクト

重要なシステムがダウンしている。 1つ以上の部門が影響を受ける。 相当数のスタッフがその機能を実行できない。 そのインシデントが多数の顧客に影響を与える。 そのインシデントが、財務上の大きな損失や組織の評判への損害になる可能性がある。 組織の機能と影響を受ける他のシステムに応じて変わるその他の基準もあります。例えば公衆の安全上の脅威、人命の喪失、または重大な財産の被害などが含まれる可能性があります。

中程度のインパクト

一部のスタッフまたは顧客は影響を受ける。 失われたサービスはどれも重要ではない。 財務上の損失や組織の評判への損害は起きる可能性があるが、範囲は限られている。 人命、公共安全、身体的財産への脅威がない。

低インパクト

少数のユーザーしか影響を受けない。 重要なサービスは関与しておらず、財務上の損失や評判の低下の可能性はほとんどない。

インシデントの緊急度

インシデントのインパクトとその緊急性を厳密に区別することは必ずしも容易ではありませんが、ほとんどの場合、このコンテキストで言う「緊急性」とは、「問題がシステムにどれだけ早く影響を及ぼし始めるか」ということだと定義できます。 給与計算システムの故障は、例えば、影響が大きい可能性がありますが、給与の支払い周期の始めに発生した場合は、毎日使う顧客関係データベースの損失よりも緊急性が低い可能性があります。

緊急度高

日々の操作に不可欠なサービスが利用できない。 インシデントのインパクトの範囲が急速に拡大しているか、または迅速なアクションによってその範囲を制限できる可能性がある。 時間に敏感な仕事や顧客の行動に影響がある。 そのインシデントが、高位の個人または組織（上級管理職または主要なクライアント）に影響を与える。

緊急度低

影響を受けるサービスはオプションであり、まれにしか使用されない。 インシデントの影響は拡大しないように見える。 重要な作業や時間に敏感な作業は影響を受けない。

注意してほしいのは、インパクトと緊急度の両方について、一般的には各カテゴリの1つの基準に当てはまればそのカテゴリになると思ってよいということです（基準のすべてまたは大多数を満たす必要はありません）。インシデントは、それが条件を満たす最も高いカテゴリに配置する必要があります。

優先度=インパクト+緊急度

以上のように考えれば、優先順位をインパクトと緊急性の両方の合算で評価すべきだと分かりやすくなったはずです。アラート管理とインシデントのディスパッチプロセスには関係なく、優先順位を決定するための基準に従ってルーティングする必要があり、結果としてアラートノイズを大幅に減らすことができ、低インパクト、低緊急度のイベントは自然に優先順位リストの下端に並ぶと思います。これにより、インシデント対応チームは、非常に注意を払う必要がある、高インパクトで高優先度のインシデントに集中することができます。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

Zabbix は、ネットワークサービス、サーバ、およびその他のハードウェア のステータスを監視するために設計された、非常に強力なオープンソースのネットワーク管理システムです。多くの組織のITインフラストラクチャを監視する上で重要な役割を果たしています。

PagerDutyはZabbixの機能を、PagerDuty APIを経由したオンコール・スケジューリング、アラートやインシデントトラッキングで拡張します。PagerDutyはZabbixの最もクリティカルなイベントを通知し、あなたが即座に対応できるようにします。

詳しくはこちら

Internet of Things （IoT） は、世界中の企業や人々の生活に普遍になりつつあります。それは目新しいものとして始まりましたが、最近ではもっと革新的でミッションクリティカルに使われるケースが出てきています。利用できるIoTデバイスが多様になり、生成されるデータも膨大になっているなか、さまざまなセキュリティ上の脆弱性が露わになり、IoTデバイスを製造する企業は多数の課題に直面していますが、ここでもインシデント解決プラットフォームが役立ちます。今日IoTシステムを構築している場合、または今後IoTシステムを構築する予定がある場合は、ベストプラクティスのインシデント解決ソリューションに投資して、IoTシステムを確実にレジリアント( 弾力性に富み) かつ安全にすることが不可欠です。

IoTシステムには統合が必要

IoTシステムには本質的な複雑さがあるため、エンドツーエンドの監視と統合が不可欠です。非常に多くのデバイスが存在し、すべてがインターネットに接続され、家庭にデータを戻してくるので、使われるのを待つだけの大量のデータがあることになります。ユーザーがIoTデバイスを使うと、使用時間と頻度、使われている機能など、詳細な使用パターンにあなた（注：サービス提供側）はアクセスできます。

監視、ロギング、およびITSM（ITサービス管理）ツールとの統合は、IoTに大きな違いをもたらし、IoTデバイスの開発者が一息つくことができます。PagerDutyのようなソリューションは、すべてを集中管理されたダッシュボードで管理し、ルールを定義してイベント管理の手順やワークフローをカスタマイズできるようにしてカオスを防ぎます。

PagerDuty APIバージョン2.0を使うとまさしくこれが可能になります。このAPIを使用すると、アプリの通知とアラート管理がよりシームレスでカスタマイズ可能になります。あなたのアプリにPagerDutyを埋め込めるだけでなく、PagerDutyにあなたのアプリを埋め込むこともできます。PagerDutyの機能は、必要なデータを表示するためにあなたが独自のダッシュボードを埋め込むことでさらに拡張できます。Custom Event Transformer（カスタムイベントトランスフォーマー）があればJavaScriptを使い、通常のデータを価値がある、そして正規化されたインシデントに変換し、PagerDutyとのカスタム統合が実現できます。

PagerDuty APIによるさまざまなIoTの統合例

PagerDutyのAPIがIoTの革新に影響を与えた事例はたくさんあります。 Resinio

Resin.ioは、IoTのクライアント、サーバ、およびデバイスプラットフォームであり、PagerDutyを使用してIoTインシデント管理を処理します。Resin.ioのようなソリューションは、DevOpsの原則と利点をIoTの世界にもたらします。Resin.ioの他の利点には、Linuxカーネルの採用も含まれており、おかげでIoTデバイス用に独自のソフトを使う必要がなくなります。これにより、開発がより身近なものになります。

Temboo

さらに、Tembooはセンサーモジュールを使った駐車場管理にPagerDutyを使っています。IoTセンサーは警報をトリガーすることができ、駐車スペースが利用可能かどうかを知るためにセンサーデータを使えるようにします。TembooとPagerDutyは、高齢者の介助にセンサーを利用することもできます。センサーを老人の生活エリアに設置すれば、手助けを求めている時に家族が通知を受けることができます。

AlertSite

別のツールで、SmartBearのAlertSiteは、IoTの品質チェックとAPIテストに役立ちます。これらのテストは手動で行う必要はなく、AlertSiteが実行を自動化します。本質的には、それは統合された複合型の監視プラットフォームであり、テスト場所から直接迅速なアラートを送信する機能や、エンドユーザーの動作をエミュレートするアラート機能も含まれています。PagerDutyはAlertSiteと統合することで実現される、最先端のエンドツーエンドのインシデント解決機能により監視機能を強化します。

起こる前に不正を防止

倫理的なハッカーは、インターネットに接続されているデバイスが、さまざまな手段で悪用されることを明らかにしました。例えばユーザーにトラブルをもたらすために機能を悪用したり、デバイスを使ってDDoS攻撃をかけるといった手口を繰り返し明らかにしてきました。インシデント管理は、IoTチームにデバイスに潜在する誤用、悪用の可能性を警告するための重要な保護層であり、特に異常に動作が起きた場合は、調整された応答をトリガーします。

インシデント管理は、それをすること自体が目標と見なされるべきものではありません。IoTが存在するためのより安全な環境を作り出すことは非常に重要です。IoTは、これまで決してできなかったような方法で人々の生活を改善することを目指しています。デバイスがそのような重要な役割を果たしている場合、インシデントの防止と修復はこれまで以上に重要になります。PagerDuty API V2.0は、IoTセントリックな未来のためにPagerDutyプラットフォームを準備するものであり、エンドユーザーと開発者のエクスペリエンスをより快適で、拡張性があり、信頼できるものにする無限の可能性をもたらします。

オンコールエンジニア は インシデント 管理 で重要な役割を果たします。 彼らは、インシデントをクリティカルな状態から管理された状態に変える役割を果たし、迅速に解決します。

スタートアップには誰がコールを受けるべきかについてあまり多くの選択肢がないかもしれませんが、組織が成長し、インシデント管理がより複雑になり、関係者が増えるにつれて、構造化されたプロセスを用意しておくことがオンコールエンジニアにとって重要になります。スタートアップ企業であれ大企業であれ、オンコールエンジニアを成功させるための明確なプロセスを用意しておくことで大きな利益を得られます。 ここにいくつかのガイドラインを示します。

最初の対応が重要

インシデント発生の最初の数分間で、オンコールエンジニアはインシデントの重大度とサービスへの影響を把握する必要があります。それに基づいて、影響を受ける下流のサービスと、誰がそのインシデントを解決する必要があるのか​​、そしてその人たちを迅速に実戦に投入する方法を判断する必要があります。これには、何かが壊れたときに根本原因を特定し、作業の優先順位を決定できるように、システムがどのように機能しているかを実践的に知っておく必要があります。オンコールエンジニアのローテーションは自動的にスケジュールされます。こうすれば負荷が分散され、チームは公平性と説明責任のために最適化され、誰もがインシデントを処理でき、接触を失うことはありません。大規模なチームでは、最初の対応を開始できる専門のインシデント管理者がいることがあります。いずれの場合も、オンコールエンジニアの主な目標は、インシデントのトラブルシューティングや解決ができない場合でも、インシデントを解決するために必要なリソースを取り込むことです。

2次オンコールエンジニアを用意しておく

2次（そしておそらく3次も）のオンコールエンジニアをバックアップとして持つべきです。 そうして、第1レベルの対応者が寝過ごして午前3時の電話連絡に気づかなくても、何も谷間に落ちないようにします。これはまた、チーム内の役割のローテーションのスケジュールが必要だということです。1次担当のエンジニアからの応答がない場合、インシデント通知がバックアップエンジニアにエスカレートされるように、自動化されたルールを設定します。

オンコールエンジニアが必要なトレーニングを

受けていることを確認する

インシデント発生時には多くの問題が発生するため、オンコールのエンジニアはプロトコルを遵守し事態の推移に遅れず考えることができる必要があります。 彼または彼女は、さまざまな部門間のステークホルダー（顧客サポート、マーケティング、PRなど）が連絡を取り合う適切な方法も理解しておく必要もあります。そうすれば修復状況を外部に伝達できます。インシデントが発生した場合に従うべきチェックリストまたはフローチャートをオンコールエンジニアに渡しておくと便利です。

ダウンタイムの1分ごとに何千ドルもの損失が発生する可能性があるため、オンコールエンジニアができるだけ早くインシデント対応をする必要があります。そのための手順は次のとおりです。

インシデントの特定とログ作成

まず、インシデントを特定または検出してログを作成します。ロギングは、問題の根本的な原因を迅速に突き止めるのに役立ち、解決後のインシデントの包括的な事後検証の進め方を示してくれます。インシデントに迅速に対応することが重要なので、特定とロギングは迅速かつ体系的に行ってさっさと次のステップに進む必要があります。

カテゴリを分けて優先順位を付ける

チームが遭遇する可能性がある問題はその種類が膨大なため、混乱を避けるためにインシデントを分類することが重要です。影響を受けるユーザーの数、影響を受けるサービスに関する問題の「爆発の半径」、潜在的な収益への影響などに注意してください。インシデントの優先順位を設定することで、オンコールエンジニアは、インシデントが残りのチームの時間とリソースを必要としているかどうかを連絡することができます。可能であれば、チーム全体の時間を節約するために、あまり複雑ではないマイナーなインシデントにはエンジニアだけで対応できるようにしておくとよいでしょう。オンコールエンジニアが重要なことに集中できるようにするため、行動不可能なアラートは抑制する必要があります。

正しい人に通知する

PagerDutyのようなプラットフォームやそれに内蔵されたChatOpsやコラボレーションは、関係する人材を採用し、その人たちを適切なタイミングで適切な場所に集めるためのベストプラクティスです。特に、特定のChatOpsチャンネル/会議室、ビデオ通話と会議での共有、コンテキスト内の問題の修正機能を使うと、解決のスピードとビジネスの影響レベルに大きな違いが生じます。チームメンバーとコミュニケーションしている間は、自分と他の人の時間を節約するために、事件の説明を簡潔かつ理解しやすくすることも重要です。チームはアラートが多すぎて注意をそらすことがあるので、PagerDutyのようなソリューションでノイズを抑え、大事なシグナルを浮き立たせることが不可欠です。

トラブルシューティング

トラブルシューティングは、チーム全体に通知して提示する場合以外でも実行する必要があります。応答を待つ間も、オンコールエンジニアのような最初の対応者はトラブルシューティングを行うことが不可欠です。最初の数分が非常に重要な現実の救急サービスと同様に、迅速な対応が救命者になれます。

オンコールリソースの管理と装備は、開発チームや運用チームが成功するための重要な作業です。十分なバックアップと十分に検討されたプロセスと計画を立てておくことで、状況が悪化した場合でも効率を確保できます。オンコールのエンジニアが上記の基本的な手順に従えば、チームは作成とイノベーションに費やす時間を増やすことができ、修復時間を短縮できます。

今日のインフラストラクチャ はあなたの祖父母の時代のITインフラではなく、1世代前のインフラでもありません。 パンチカード、真空管、フェライトコアメモリー、フロッピー、ダイヤルアップインターネットの時代はもう終わりました。

そして今日のインフラは、5年前、あるいは1年前のITインフラでもありません。 現代のインフラは絶えず変化しています。この記事で私たちにできるのは、インフラのスナップショットを見せ、それが今度どうなるのかという一般的なイメージを伝えることです。

インフラの効果的な監視には、今日のインフラの様相とそれがどう変わっていくか、将来何がそこに含まれることになるのかを理解しておく必要があります。

ハードウェア：たぶんムーアの法則の予想を下回る

ハードウェアインフラは比較的安定しており（「相対的に」という言葉が強調されています）、数年間は半安定の状態にあります。 ムーアの法則が限界に達しつつあるという推測は時期尚早ですが、Mooreの法則が描く曲線は、少なくともプロセッサ速度とRAM容量（大容量ストレージは別の話かもしれない）に関しては、部分的に平準化しつつあるようです。

ソフトウェア：変化するのが自然

この平準化は、ITインフラの最も重要な変化がソフトウェア側で起きていることを意味します。これは驚くべきことではありません。なぜなら、現代のインフラはかなりの部分をソフトウェアに負っているからです。 SDN(Software-defined networking)、仮想マシン、コンテナなどは、今日のハードウェアとソフトウェアの間の線が事実上ひどくあいまいになっていることを示しています。

ソフトウェアとしてのITインフラが現代のコンピューティングの大事な要素だということは驚くべきことではありません。 結局のところ、ハードウェアは基本的にフレームワークであり、何かを可能にするために設計された構造です。 その可能性を利用できる人は、世界にあらゆる違いを生み出すことができます。

ハードウェアの遅れから解放される

ソフトウェアベースのインフラへの移行は、これまでのプラットフォームの変化をはるかに超えた意味を持ちます。一つは、ハードウェア自体の変更の速度に大きな遅れが見られることです。物理サーバー、ネットワーク、および周辺機器を交換またはアップグレードするには、費用がかかり、時間がかかるので。その必要性が明確になるまで（またはなった後まで）、多くの組織が長い時間待って、それからハードを更新していました。この遅れはほんの数年かもしれませんが、レガシーなハードウェアとそれに必要なレガシーなソフトウェアの両方を共存させることを要件としたために、ソフトウェアレベルにもインフラのハードウェア自体にも影響を与えました。

しかし、現代のソフトウェアベースのインフラでは、アプリケーションソフトウェアとインフラを構成する要素の両方が、基本的なハードウェア要素の大部分（全てではないにしても）から隔離されています。ハードウェアが抽象化レイヤーの要件をサポートできる限り、インフラ自体にはハードウェアの遅れの影響がほとんどありません。

「ソフト」要因

結果として、インフラソフトウェアとアプリケーションソフトウェアの両方の変化の速度は、現在の組織文化やソフトウェア設計と開発の速度に関する現実の制限などの他の要因に支配されています。 これらの要因は一般的に「ソフト」的であり、それが課す遅れははるかに短く、特定の組織内の一般的な状況により多く依存しするようになっています。

今日のインフラ

つまり、今のコンピューティングへの理解は、現代のITインフラの現状を今のこの時点でとらえたスナップショットに過ぎないことを意味します。 そのようなスナップショットには何が含まれているでしょうか？ 大事な要素は次のようになります。

クラウド。インフラが抽象化された複数の層の上に位置するソフトウェアである場合は、それが特定のサーバーまたはネットワークのセットに結び付けられる理由はありません。 クラウド（基本的に高レベルの抽象化レイヤー）は、開発者が相互作用する最も基本的なインフラになります。 開発者が作成し管理するインフラは、それがVM上で実行されているアプリケーションであっても、仮想化されたホストシステム上で実行されているコンテナで構成されているものであっても、実質的に完全に仮想化されています。 仮想化。 仮想化は既存のものとなっていて、私たちは今この事実の意味を理解し始めているだけです。 既存のオペレーティングシステムはもともとハードウェアによって課せられた制約を念頭に設計されていました。 ハードウェアに課せられた制限を参照することなく完全に設計されたシステムはまだありません。

しかし、現在のオペレーティングシステムの限界があっても、標準となった仮想化を使えば、アプリケーションだけでなく、それらが存在する環境も、伝統的なOSで実行された簡単なプロセスと同じくらい簡単に、作成、管理、 破壊できます。

パイプライン全体の自動化** インフラがソフトウェアの場合、他の種類のソフトウェアを管理するのと同じ方法で、インフラを管理するのが合理的です。 また、この自動化をソフトウェア配信パイプライン全体にわたって拡張することも合理的です。それがパイプラインの全プロセスを管理するための単一のシステムの形を取ったとしても、あるいは必要に応じてタスクを互いに引き離す一連のスクリプトの形になったとしてもです。

伝統的に、自動化はしばしばスケジュール駆動型でした。 しかし、現代のインフラストラクチャーでは、通常、イベント駆動型です。 これにより、より大きな柔軟性が得られ、不要な遅延が排除されます。

切れ目のない配送**。 そういうフレキシブルな応答駆動型の自動化は、当然、継続的な配信につながります。 手作業による介入や配送プロセスによる遅れがないのですから、連続してはならない理由はありません。

実際、配信が途切れ途切れになっていた理由は、通常、仮想化されていないインフラと配信パイプラインが自動化されていなかったからです。 仮想化されたソフトウェアベースのインフラを完全に自動化する機能と組み合わせることで、ハードウェアベースのインフラの制約に対応する必要性がなくなり、継続的な配信が可能になりました。インシデント管理で継続的な配信を最適化する方法については、こちらをクリックしてください。

https://www.pagerduty.com/resources/learn/continuous-delivery

では、今日私たちはどうにコンピュートするのでしょうか？ 私たちは仮想化され、抽象化の複数のレイヤーによってハードウェアレベルから隔離された環境でコンピュートしています。 当社の開発およびデプロイメントパイプラインは、イベント駆動型の自動化によって途切れることなく管理されています。 多くの点で、現代のIT環境は、従来のハードウェアベースのIT世界から隔離された仮想世界になっており、数年前にITを支配していた懸案の多くが無関係になっています。

バーチャルな明日？

以上が今日のスナップショットだとすれば、明日は、さらに5年先、10年先はどうなるのでしょうか？　もちろん、実際に知る方法はありません。今日の予測は、時間が経つにつれ、だんだんと的外れになる可能性があります。

しかし、ここにいくつかの他の予測があります。ハードウェアによって課せられた制約から仮想コンピューティング環境を解放する効果が見え始めたことがその1つにあげられます。また、仮想化されたコンピューティングと、バーチャルリアリティと、昔からの物理的な経験の区別が崩壊する可能性があります。多くの点で、今日のコンピューティングの変化の速度は、私たちの能力によって制限されています。つまり変化が発生したときにそれを私たちが吸収し、発達するにつれてその力をフルに活用する能力によって制限されています。しかし、自動化とインテリジェンス機能は、垂直でもドメインでもほぼ全ての機能を破壊的に変え、効率性の新たな可能性を広げ、人々の作業の焦点を劇的に変える可能性があります。

おそらくコンピューティングと日々の経験の両方の仮想化は、将来の変化を吸収する速度を早めます。私たちが未来のクリエーターになり、未来に参加する可能性が高いとしても、このような場合、もし今私たちがその一部を垣間見られたとしても、将来のコンピューティングと人間生活の両方が完全に理解不能になります。世界を変えるなら私たち自身も変えることになるのです。

フェイスツーフェイスで話をする。

プラットフォームになることの大きな点の1つは、ユーザーが、自分とは異なる方向に製品を持っていけることです。 私たちはあなたの好みの電話会議ツールをインシデント対応プロセスに組み込めるようにしました。以前自分のインシデント対応にビデオ会議を追加するんだと冗談を言っていたお客様には、どうやってオペレーションコマンドコンソール に追加するかを教えましたけれど。

私は、インシデントの間に私のブサイクな顔を見たい人がいるなんて思ってなかったんです！

以下は私たちがやった通りのソリューションではありません、オーバービューです。

iframeに埋め込むことのできるビデオ会議ツールを使用します。この例ではAppear.inを使用しています。 サインアップのプロセスがないので。

操作コマンドコンソールを開きます（まだこの機能を試していない場合は営業担当者に相談してください）。インシデントのコンテキストで表示する場合は、これをワークフローの拡張にすることもできます。

コンソール設定に移動し、「カスタムURLモジュール」を追加します。 これはしばらくの間ベータ版であった機能で、顧客はチャット、wikiページ、エーテルパッド、ステータスページをこのように埋め込んでいます。 私のURLはht​tps://appear.in/diligent-quailでした。

以上でおしまいです！

これで自分のチームがオペレーションコマンドコンソールを使ってインシデント対応を調整しているときに、お互いの集中している様子見てほめあうことができます。 次は、Snapchatフィルタを追加する方法を理解する必要があります。

あなたのチームがPagerDutyプラットフォームを拡張した妙だけど素晴らしい方法はいくつあります？　[email protected]で電子メールを送って知らせてください！

7つのステップでアプリケーションの高可用性を確保する

2016年8月、デルタ航空はコンピュータシステムの大々的な停止を経験しました。これにより1億5000万ドル以上の損害を被り、全社の利益率が3％低下しました。2300便がキャンセルされ、顧客は空港に何時間も足止めされました。デルタ航空は移動できなくなった人のために、何千件ものホテル代と旅行クーポンを支払う必要がありました。

数百万ドルするアプリケーションやサービスでも、いつダウンするか分かりません。大きな問題が1つでも発生すると、数億ドルの損失が発生する可能性があります。しかし、次のような対策をとれば、これを大幅に回避することができます。

1.マイクロサービスアーキテクチャを採用する

伝統的に、アプリケーションはモノリシックなスタイルで、つまりアプリ全体が1つのプログラムとして開発されていましたが、今ではマイクロサービスアーキテクチャが大いに普及しつつあります。その開発、テスト、デプロイには、相互に依存しない小さなアプリケーション群を配置します。こうすると、アプリケーションのコンポーネントが互いに分離されているため、保守が非常に簡単になります。したがって、特定のコンポーネントの1つに障害が発生した場合、他のコンポーネントに影響を及ぼすことなくフィックスすることができます。モノリシックアプリケーションでは、障害が起こるとアプリケーション全体がダウンするため、問題を特定するのが困難です。マイクロサービスのアプローチは、アプリケーションのダウンに対する耐性を高め、高可用性を実現するための第一歩です。ただし、マイクロサービスアーキテクチャでは、生成されるモニタリングデータの量がはるかに多く複雑になるため、関連するアラートを相関させ、対処不可能なアラートを抑制して全体的なノイズを削減することが重要です。

2.リリースはより速く、より頻繁に

マイクロサービスアーキテクチャの最大のメリットは、Webアプリの場合は1日に複数回、モバイルアプリの場合は2週間に1回などの高速リリースを可能にすることです。以前は四半期ごとのメジャーリリースだったため、すべてのリリースでダウンが避けられませんでした。現代的なアプローチではリリースは断片化しています。デプロイメントは、いつでもバックグラウンドでアプリケーションの一部でのみ行われ、プラットフォームは常に稼働したままになります。これにより、ダウンするリスクが軽減されるだけでなく、リリース速度を上げて最先端の機能と価値を提供することができます。

3.品質保証チームの関与

品質と可用性が同時に高まります。多くの企業ではQA（品質保証）の重要性を理解することができず、最終段階までそれを無視しがちです。バギーなソフトウェアを防ぐために、QAチームは、可能な限り早期に開発プロセスに関与し、リリースのライフサイクルに密接に関わっている必要があります。QAチームは自動化とテスト戦略に力を注ぐべきです。テスト自動化フレームワークは、手動アプローチと比較してコストを大幅に削減し、時間を節約しながらエラーを最小限に抑えるのに役立ちます。さらに、テスターはバグを探すだけではありません。彼らは開発を適切な方向へ向けるために、要件定義にも積極的に関与しなければなりません。開発チームが最初から正しい方法を構築することによって、後々の憂いをなくすことができます。QAは継続的な改善なのです。

4.ディザスタリカバリー計画を立てる

アプリの中核サービスに障害が起きたときのために、優れたディザスタリカバリー計画が必要です。パブリッククラウドとプライベートクラウドによるハイブリッドアーキテクチャを採用している企業では、サーバに冗長性を持たせ、各クラウド間でバックアップを取ることが重要です。仮想化は、既存の物理サーバのイメージバックアップを作成するのに便利です。また、コンテナ化することはさらに有用です。これは、イメージバックアップが軽量でスペースをとらないためです。これらの戦略は、障害時でもデータを確実に利用できるようにします。さらに、adminがおらず権限がない場合でもバックアップを取れるよう、バックアップを自動化しておきましょう。自動化により、DevOpsチームはディザスタリカバリーをテストして、障害への準備を整えることができます。

5.ITSM変更管理を採用する

ITILのような標準化されたフレームワークがITSM（ITサービスマネジメント）変更管理に使用されていることを確認してください。変更はそれがなければ進歩がないほどITサービスにとって有益ですが、変更は常に文書化されなければなりません。変化の成功率を測定し結果を公表して、どのチームが成功率が低いかを調べます。ServiceNowのようなITSMツールは、変更管理の可視性と制御性に優れています。ITサービスの混乱を最小限に抑えながら、迅速かつ効率的に変更を加えることができます。

6.インシデント管理ツールを使用する

避けられないシステムダウンが発生した場合、チーム内の適切な人にリアルタイムで通知することが重要です。しかし、多くの場合、チームはあまりにも多くのアラートを受け取るため、MTTR（解決までにかかる平均時間）に影響する重要なイベントを見逃す可能性があります。PagerDutyのようなインシデント管理プラットフォームは、さまざまな監視システムからのアラートを管理しグループ化するのに役立ちます。それは、簡単に定義されたルールに基づいて対処不可能なアラートを抑止し、関連する対処可能なアラートをインシデントにグループ化し、優先度の高いインシデントだけを適切な人物に通知するようにします。さらに、PagerDutyは既存のすべての監視、チケットシステム、ChatOps、コラボレーションツールなどとの統合により、チームがインシデントの解決を迅速に行います。

7.障害訓練を行う

計画的に障害を起こすことによって、システムダウンに対する準備をします。Netflixはこのアプローチをとっていることで有名です。彼らは常にバックグラウンドで実行されていて、ランダムにサーバインスタンスをシャットダウンするChaos Monkeyというスクリプトを使用しています。これにより、本物のサーバダウンが発生した場合でも、常にチームは準備ができており、スムーズに顧客にサービスを提供できます。PagerDutyでも毎週「Failure Friday」を実施し、意図的にシステムに障害を発生させ、対応を継続的に改善しています。

完全な対策を達成することは不可能ですが、DevOpsチームを構成する人、プロセス、ツールに焦点を当てることで、それに近づくことができます。すべてのシステムダウンを解決する銀の弾丸はありませんが、これらの手順に従ってより信頼性の高いアプリケーションを構築し、顧客の信頼と忠誠を獲得し維持しましょう。

「カオスエンジニアリング とは、本番環境の分散システム が混乱状態にさらされても耐え抜く能力を実証する実験」―カオスエンジニアリングの原則

Netflix、Dropbox、およびTwilioは、カオスエンジニアリングを実行している企業です。彼らには自社の大規模で堅牢な分散システムに自信を持つことが不可欠です。PagerDutyでは、数年間、本番環境にフォルトインジェクション（一部のサーバ、サービスを落としたり負荷をかけるなどしてシステム全体の堅牢性を確認する手法）を行ってきました。時が経つに連れインフラが成長し、私たちのカオスエンジニアリングの技術も進化しました。最近追加されたものの1つに、ChaosCatと呼ばれる自動フォルトインジェクタがあります。

バックグラウンド

当初、PagerDutyのSRE（Site Reliability Engineering）チームは、SSHを使用して各ホストでコマンドを実行するという、手動のフォルトインジェクションを行っていました。これにより、障害を正確に管理し、発生した問題をすばやく調査し、ツールへの大きな先行投資を避けることができました。これはしばらくの間うまくいっており、高ネットワーク遅延、高CPU使用率、ホストの再起動など、反復可能なカオス攻撃のライブラリを構築することができました。

私たちは手作業で行っていてはスケールしないと分かっていたので、時間の経過とともにプロセスの一部を自動化し始めました。まず、個々のコマンドはスクリプトに変換され、SSHの代わりにホストで自動的に実行するようにしました。それぞれのチームがPagerDutyで独自のサービスを開始した後にこのツールを使用することで、SREチームを必要とせずにフォルトインジェクションができるようになりました。

しかし早い段階で、各サービスの責任者が既知の障害を起こすプロセス作ることにしました。これは、毎週金曜日に責任者が何を調査すべきかを少なくともいくらかは認識していることを意味していました。それは、彼らが問題を解決するためのスタートでした。

現実の世界では障害の予兆が出ることはめったにないため、任意のホストでランダムに攻撃のサブセットを実行できるようにすることで、システムに偶然の要素を導入したいと考えていました。そのため、ツールを追加してランダムにホストを選択し、それらに対してカオス攻撃を実行しました。パズルの最後のピースは、すべて自動化されたスケジュールにまとめられていました。

実装

ChaosCatはScalaベースのSlackチャットボットです。分散型タスク実行エンジンなど、我々のインフラのいくつかの別コンポーネントの上に構築されています。Chaos Monkey（Netflixが開発、利用しているオープンソースのフォルトインジェクタ）の影響を強く受けていますが、我々のインフラにはさまざまなサービスタイプが存在するため、サービス実装には依存しない設計になっています。

ChaosCatは常時稼動のサービスとして動作しています。これは、許可されたチームがいつでも使用できることを意味します （「@chaoscat run-once」で実行） 。サービスがアイドルの間はスケジュールが1分ごとにチェックされ、オンコールエンジニアがいることが確実な営業時間中にランダムに障害を発生させます。

営業時間になったら、システムステータスがすべてクリアかどうかをチェックします。サービスの健康状態が100％でない場合には障害を発生させないためです。

次にインフラ内の無作為に抽出されたホストに対してランダムに選択されたカオス攻撃（異なる選択確率を持つ異なるアタック）を発生させます。現実世界では例外なくすべてのホストが同様に脆弱だからです。社内のジョブランナーを使用して、Blender実行フレームワークを介してカオス攻撃を実行するタスクを送信します。

10分待ってから、スケジュールされた営業時間の間に、2つ目と3つ目のステップを繰り返し実行します。問題が発生した場合、誰でも「@chaoscat stop」を送信することによって攻撃を停止することができます。

学習

いくつかのチームは、こうしてダッシュボードとログの準備が整った状態で座っている時と、モーニングコーヒーを飲んでいる間にトラブルが生じた時とでは何か違いがあることをすぐに知りました。これらのチームは、ランニングブックとオンコールローテーションのギャップを特定し修正しました。大成功！

もう1つの興味深いことは、チームが最初の苦労を乗り越えた後、以前に手作業で行われた修正を自動化し、バックログに不具合の優先順位付けしたことです。その結果、このチームはサービスの信頼性に自信を持ちました。

残念ながら、ChaosCatは社内のインフラストラクチャツールに大きく依存しており、現時点では、オープンソースではありません。しかし、私たちはあなたのフィードバックと質問をお待ちしています。

このような信頼性のためのエンジニアリング―カオスエンジニアリングを開始する企業が増えることを期待しています。それは複雑さと多様性が増すインフラの堅牢性と動作を検証するうえで素晴らしい方法です。

3年前、私は 新興スタートアップだったPagerDutyにエンジニアリングマネージャーとして参加しました。 当社は2013年にシリーズAの資金を受けて超成長モードにあり、あらゆる分野で積極採用を進めていましたが、エンジニアリングチームは当時30人以下でした。急成長企業が直面している構造的課題の解決に、私は大きな魅力を感じました。エンジニアリングが100人のDutonian（注：Star Wars: The Old Republicに登場する）の群に増えつつある今、これまでの変化を振り返り、今後に反映させようと思います。

組織構造の進化は魅力的なプロセスです。それはたくさんの間違い、行き止まり、車輪の再発明みたいなことでいっぱいです。うまくいけば、エンジニアリング組織をカバーする文献はたくさんあります。その多くは、賛否両論の抽象的なリストみたいなもので沸騰しています。また企業が採用したプロセスを自画自賛するようなブログ記事も投稿されています。私は別のアプローチをとって、エンジニアリングチームが構造を進化させる試みを繰り返し、それに伴って起こった誤解や学びのすべてを包括して、そこから歴史的な教訓を得たいと思います。

注：イベントや詳細の一部は、ストーリーを分かりやすくするため省略しています。このブログをブックマークしておくと、新しいコンテンツを見ることができます。

昔はサイロ化した組織でした

2014年初頭のPagerDutyは次のように見えました。

エンジニアリング組織は、サンフランシスコ（SF）とトロントのオフィスに分かれていました。

運用チームは、インフラストラクチャの自動化、セキュリティ、およびパーシステンス（SFのみ）を担当しました。

WebアプリケーションチームはPagerDutyの顧客に

見えるの部分を担当し（SFのみ）、主にRuby on RailsとMySQLで

開発をしていました。

バックエンドサービスグループは、信頼性の高いデータ収集と通知配信を担当し（SFとトロントにチームが分割配置されていました）、主にScalaとCassandraで開発をしていました。

DevOpsには部分的な遵守事項しか明文化されていませんでした：

運用チームは、インフラストラクチャ監視アラートのオンコールを担当し、他のチームは導入したコードのオンコールを担当していました。

エンジニアリングが非常に短期間に少人数からいくつかの分散したチームへと成長する中で、製品開発プロセスは未成熟なままでした。スタンドアップとスプリントを使い表面的には敏捷に動いているように見えていたにもかかわらず、基本的にウォーターフォールモデルを使っていました。リーダーシップは、作業すべきプロジェクトを定義し、個々のエンジニアをそれらのプロジェクトに割り当て、目標とする納期を定義しました。予想通り予定はあまり守れずプロジェクトのスプレッドシートは壊滅的な状態になりついには使われなくなりました。

事態はうまく進むように見えませんでした。プロダクトマネージャーは、開発中に発生する可能性のある疑問を予期して詰め込んだ長い機能設計仕様書を作って新しいプロジェクトを開始しました。プロダクトとエンジニアリングは実際には開発中にはあまりやりとりをしないのに、です。この仕様では、Webアプリケーションとバックエンドサービスチームに提示され、ユーザーチームとバックエンドの側面を個別に担当しました。新しいインフラストラクチャのリクエストは、数週間前に運用チームに提出する必要がありました。

こうした努力の数々をすべて一貫した機能リリースに統合することは悪夢でした。我々は不完全なインフラしかなかったり（またはまったくインフラが用意されていなかったり）、バグ、機能ギャップ（各チームが、きっと他のチームがそれをやっていると思いこんでたのです）、エンジニアと製品の両方のオーナーシップやエンパワーメント、日数不足、組織のサイロ化や不整合がありました。期限通りに出したいという欲が、リスクテイクを減らすことにつながりました。私たちは実装においてより慎重になり、製品の仕様を調整することに嫌気しました。

この部門の構造と開発プロセスの組み合わせは、その年のエンジニアリング内の他のすべての議論の最前線にサイロの話題を押し上げました。 おーい僕らはサイロに落ちているんじゃないの？と。

Webアプリケーションvsバックエンドサービス 2つのグループの間 には緊張がありました。 どちらも他のグループが取り組んでいたことをちゃんと理解しておらず、不満でした。

Ruby vs Scala 上記と似ていますが、特定の言語を中心に多くの「自転車置き場」（注：本当に必要か、どこに作るべきかをきちんと検討せずに作られたものを指す）やアイデンティティを構築していました。

オペレーションvs開発チーム。両方とも開発チームがすべてのサーバープロビジョニングのボトルネックとなっていることに不満を抱いていました。オペレーションは迫りくる締め切りに大きなプレッシャーを経験していました。

サンフランシスコvsトロント。 地理的に2つの場所に分かれたエンジニアの間で、同じ場所にあるエンジニアはまとまり、はっきりとした「彼らと私たち」の雰囲気が生まれました。 両陣営は何かと相手に不満を募らせました。

責任の集合を厳密に定義すればチーム間の機能的な連携に多くの余地を残すことはありませんでした。 私たちは、「ワーキンググループ」という概念を試してみたこともあります。小規模で一時的で多様なチームが責任範囲と日程が明確な横断的なプロジェクトに取り組むことを目的として、既存のチームからメンバーを編成しました。こうした取り組みは、プライマリチームを不安定化させて混乱を招いてしまったので、実験は中止されました。

でもみんなで協力してより高い整合性と予測可能性を顧客に提供することが一番大事なことでした。みんながサイロ化に悩んでいたので、解決しなければならなかったのです。私たちはなんとかやり遂げました。

マトリックス化した組織に

2015年の初めには、物事の状態への不満やアジャイル・メソドロジへの関心の高まりが重大になり、部門別に同様が生じました。特定の製品の方向性に合わせていくつかの新しいチームが結成されました。彼らはScrumプロセスに従い、Webアプリケーションとバックエンドサービスチームのエンジニア、製品所有者、Scrumマスター、UXデザイナーで構成されていました。

前年度の製品進捗状況が理想的ではなかったことを考え、新しいチームは製品提供のために最適化されていました。新しい機能の導入に100％時間を費やすことができるように、メンテナンス作業はバックエンドサービスチームに委任されました。これらはKanbanの方法論を採用し、「ベースチーム」として知られるようになり、プロダクト内のすべてのオンコールの責任を含め、すべてのサービスのオーナーシップを取りました。さらに、製品チームに供給された基本チームは、製品作業の増加に伴い、エンジニアが一方から他方に移行しました。

これらは明らかに大きな変化でした。個々のエンジニアへのチームシャッフルの影響を最小限に抑えるため（また、リモートレポートを処理することをやめるため）、レポート関係には触れませんでした。これはもちろん、皆さんの人生を驚異的に複雑にしました。なぜなら、マトリックス型の組織という二重のレポート構造を持っていたからです！多くのエンジニアは、直属のスーパーバイザーに割り当てられていないチームに所属し、マネージャーは、「人事マネージャー」（人員を管理。他のチームに所属する人も含みます）と「機能マネージャー」になりました（チームを管理。一部のエンジニアは別の人にも報告をしていました）。

良かった点は、古いサイロがほとんど壊されたことです。それが復活することはありませんでした。バックエンドサービスエンジニアと緊密に連携するWebアプリケーションエンジニアは、互いの違いを認識しながら、共通の目標に向かって進むことができました。もっとも、ほとんどのチームは地理的にも分散していたため、2つのオフィスを統合するのを不思議に思っていましたが。

悪いニュースは、新たな問題が発生したことでした。

テクニカルメンテナンスに関係するチームを結集することは非常に困難でした。ベースチームは、長期のロードマップを形成し、すべてのプロダクションサービスの運用上のオーナーシップをとる羽目になりました。

フィーダーモデルが各チームの結束に非常に大きな影響を与えました。チームの構成を何度も変えていくことは、士気にはあまり良いことではないことが分かりました。

二重のレポート構造はとても非効率でした。直接のレポートでは日常的な活動が見えず、人事マネージャーと機能マネージャー間ではコミュニケーションのオーバヘッドが起き、責任に関して混乱がありました。

私たちは、敏捷性よりもむしろアジャイルプロセスを採用しました。Scrumは、過剰な仕様、統合、製品のオーナーの関与を確かに助けました。しかし、ソフトウェア配信に対する当社のアプローチは変わらず、機能リリースは依然として価値があるかどうか怪しいという大きな問題があるものでした。

より多くのチームがオペレーションの人々に多くの負荷をかけました。インフラストラクチャの要求が頻繁になり、新しいサービスごとにオンコールの責任が追加されるため、このアプローチは拡張されませんでした。

すべてのことを考慮すると、私たちはまだ1年前よりずっと良い形になっています。

しかし、まだまだ道のりはまだまだありました。

アジャイル組織

新しい組織体系で1年間生活した後、私たちはかなりの数の学習を蓄積しました。 アジャイルはうまくいっていましたが、十分な作業はしていませんでした。DevOpsはうまくいっていましたが、十分に機能していなかったので、マトリックス管理はそれほど良くありませんでした。

2016年の早い段階で、我々は再び再編した。 「垂直」製品スクラムチームは現在、製品の特定の部分を担当していました。 「水平」チームは、製品やインフラストラクチャの問題を横断する責任があり、ベストプラクティスを設定し、他のチームが速やかに動くことを可能にしました。 プロダクトデリバリーチームは、ロードマップ、要件定義、実装、デプロイメント、運用中のコードとインフラストラクチャ（！）の保守を所有していました。 私たちは真の開発者を採用しました.Ops「あなたはそれをコードします、あなたはそれを所有しています」アプローチ。

これは以前の懸念をどのように解決しましたか？

メンテナンスチームはこれ以上ありません。各チームは製品やインフラストラクチャの一部を所有し、迅速に移行し、革新する権限を与えられました。

フィーダーチームはこれ以上ありません。特定のチームに対して人員が開かれました。

もう二重報告はありません！組織として、遠隔のエンジニアの採用と管理をより快適にしました。物理的な距離がもはや障害ではなくなったので、私たちはマネージャーを点線関係のないチームに割り当てることができました。

私たちは物事を終わらせることに集中しています。 GSD（Get Sh * t Done）のマントラは、チームが実用的で生産的で機敏なデリバリーマシンに成長するために、過剰仕様化とオーバーエンジニアリングのイントロスペクトと遺産を捨てるようにチームに挑戦し、私たちの集団意識に浸透しています。

セルフサービスで成長が可能。オペレーションチームは、あらゆる種類のインフラストラクチャニーズに対応できるように、魅力的なChatOpsツールを提供するなど、製品配信チームに力を与えるために多くの作業を行いました。これはDevOpsを徹底的に採用し、インフラストラクチャのアラートをOpsから、実際のホスト（問題をより速く解決できる人）を持つ関連チームに移動するための鍵でした。

GSDの主題はもう少し詳しく調べる価値があります。練習を通して、私たちは、チームの自律性、発明よりも革新的なアイデア、そして実現する解決策ではなく解決するための問題をビジネスにもたらします。顧客にとって何がベストかを知っているという考えを放棄するのは容易ではありません。実行可能な最小限の製品を提供し、開発サイクル中に即座にフィードバックを取り込み、それを組み込むことに重点を置いたのが、レーザーの焦点でした。迅速に反復し、価値を最大化し、金めっきを最小限に抑え、数ヶ月から数日または数週間の間にプロトタイプを顧客の手に渡す時間を短縮することができました。言い換えれば、「アジャイルプロセスに従う」組織から実際のアジャイル組織に変化しました。

製品納品チームの数が増えるにつれて、興味深い現象が発生しました。いわゆる「部族」（Spotifyのチームモデルに対するハットチップ）、つまり共通の機能や共通の使命でチームのグループが出現しました。これらの取り決めにより、共有された所有権、知識の共有、ロードマップの共有（個々のチームのバックログとは別）、共有されたビジョンなどの利点がもたらされました。部族組織は私たちがまだ実験しているものです。部族との習得についての今後の更新についてお楽しみください。

私たちはこの構造で16ヶ月稼働しています。確かにチームと関連するオーナーシップラインは、会社が急速に成長し続けるにつれて進化します。同時に、正しいことがどのように見えるかを知るために、間違ったことを十分に行ったことは明らかです。

学んだ教訓

私が早期に決定したいくつかの決定と、組織が耐え忍んだ厄介な中間的な状態のいくつかに戻って考えると、私は頭の中で自分自身を叩きつけ、 明らかに優れた終わりの状態。 もちろん、現実は決して簡単ではありません。その決定は当時の国家、優先順位、国民、そして私たちの課題の関数でした。 あなたは自分の挑戦のいくつかを認識しているかもしれません。その場合、あなたは私たちの経験から何かを取り除くことができると願っています。

私がそれを何度もやり直さなければならない場合、これは私が私と一緒に持ってくる学習です。

チーム間の依存関係を最小限に抑えます**。 依存関係は、ブロック、バグ、誤解、悪い気持ちにつながります。 チームが他の人たちを待つことなく提供できるようにすると、生産性が大幅に向上します。

チーム構成の変更を最小限に抑えます**。 ビジネスの現実は、時折、リソースをある場所から別の場所に移す必要があることを指示しています。 チームの士気と生産性に重大な影響を与える可能性があるため、人を動かす前に長く考えてください。

チームの所有権と責任を過度に処罰しないでください**。 ここでの柔軟性は、長期的な勝利につながります。 チームに自分の問題を解決させるよう促し、前の2つの点で問題が少なくなります。

継続的な学習と実験を恐れないでください**。 これはコード、プロセス、組織といったすべてに適用されます。 同じことを何度も何度もやり続けると、1つは良くなりません。

アジャイルプロセスは素晴らしいです。アジャイル・カルチャーが優れています。スタンドアップとスプリントレビューは、自分自身で大きな価値をもたらすわけではありません。実行可能な最小限の製品、迅速なフィードバックループ、およびコラボレーションに焦点を当てることは、文化的な変化を必要としますが、提供される顧客価値を最大化します。

コードの運用上の所有権はチームと一緒に存続する必要があります。システムの信頼性、コード品質、および組織のスケーラビリティのバランスをとるための最良の方法です。

クロスファンクショナル、フルスタックのチームが製品の配送に最適です。これは、上記の依存性の最小化ポイントと非常によく似ています。各チームは、外部の専門家やプロジェクトのハンドオーバーを必要とせずに、要件の収集から展開に移行できる必要があります。スペシャリストチームには場所がありますが、以前に議論された「水平」チームの領域ではより多くのものがあります。

どのような環境でも動作できるジェネラリストを雇う。チームメイトは、技術と技術の方向性が変わるにつれて、特定のツール、フレームワーク、スタックにアイデンティティーの感覚を付けてはなりません。成長の著しい環境で成功するために最適な人材は、仕事に適したツールを学習して使用することに重点を置いています。したがって、学習と成長の機会を提供する準備ができていること。

あなたがそれを助けることができるならば、行列での管理を避けてください。 二重報告が解決するように見えるかもしれない問題に対処する他の方法があるかどうかを検討してください。

分散チームを受け入れる。 離れたメンバーと緊密なチームを構築することには課題はありませんが、そのメリットは多くあります。 Martin Fowler氏は、「チームを遠隔地にすることで、チームにもたらすことのできる人の範囲を広げることができます。 遠隔地のチームは、同一のチームが同じ場所にいる場合に比べて生産性が低いかもしれませんが、あなたが形成できる最高の共同チームよりも生産性が高いかもしれません。 、より強固なチーム全体を構築することができます。

組織が成長し成熟するにつれて、減速し、石灰化し、より保守的になる傾向があります。 継続的な改善を実践し、プラクティスを進化させることで、我々は負に陥らないようにし、時間をかけてより機敏で、実用的で、生産的に成長することができました。

3年間（そして多くの）の学習の成果がここにあります！