Blog
ブログ

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年間（そして多くの）の学習の成果がここにあります！

シンプルな 世界では、すべてのアラートは等しく発行され、インフラストラクチャは 完全に機能しているか、完全に壊れているかのどちらかで、その中間はありません。

しかし、実際には、世界はそれほど単純ではありません。インフラストラクチャがこれまで以上に多様で複雑な今日は特にそうです。

その複雑さに対処するには、監視とアラート管理に異なるアプローチが必要です。やって来るアラートに順番に応答するプロセスとして、またはすべてのアラートがアクションを必要とすると仮定して処理するよりもはるかに多くのことを要求されます。

この記事では、アラート管理に対する柔軟で微妙なアプローチが不可欠である理由と、その実装方法について説明します。

複雑化した現代のインフラ

柔軟なアラート管理プロセスが不可欠な理由を理解するために、現代のインフラストラクチャを複雑にする要因を検討してみましょう。次の点を考えてください。

階層化され相互依存しているインフラストラクチャ

以前はベアメタルのサーバとワークステーションがたくさんありました。今日、すべてがソフトウェアで定義される時代に、インフラストラクチャは物理マシンと仮想マシン、ソフトウェア定義のネットワーク、シンクライアント、断続的に接続されたセンサーなどからなる複雑なスタックであり、相互に絡み合っています。その結果、Docke化アプリケーションなどの1つのソースから発せられるアラートは、実際にはインフラの他の部分に根をもつ可能性があります（Dockerホストサーバが接続されているストレージアレイなど）。

いくつかの問題はより深刻

これは、インシデント管理の経験がある人にとっては自明のことです。それでも、今日の問題の範囲がどれくらい広がっているのか、アラートの重大度をすばやく解釈することがどれほど難しいのかを強調しておきましょう。たとえば、ストレージサーバが応答を停止したことを知らせるアラートは、一見すると非常に深刻に思えるかもしれません。ただし、サーバが自動フェイルオーバーを備えたスケールアウトされたストレージクラスタの一部である場合、ダウンタイムは実際には最優先事項ではありません。データが失われる可能性は低く、チームがすぐに問題に対応しなくともビジネス継続性は中断されません。さらに、一部のアラートは警告としては機能しますが、すぐに対処可能ではありません。その情報は、インフラストラクチャ全体のレベルでの異常検出のために保持する必要がありますが、アラートの嵐に疲れてしまわないために、人間の反応のトリガーにならないよう抑止する必要があります。

リアルタイム応答の重要性

今日の常時稼働の世界では、ユーザーはサービスの失敗をリアルタイムで知ることができます。したがって、アラート管理プロセスはリアルタイムでも発生する必要があります。あなたの会社に連絡する前に、SNSのような公開の場所に書き込む傾向があるという事実は、リアルタイム解決をより緊急事項にします。反応的ではなく積極的に行動する、顧客が怒りのツイートをするまでアラート対処を待つことは望ましくありません。

アプリケーションパフォーマンスの問題

アプリケーションが実行されていることを単に確認するだけでは不十分です。ユーザーはパフォーマンスの低下に対してほとんど忍耐力を持たないため、パフォーマンスを最善にする必要があります。たとえば、Webサイトの速度が遅い場合、顧客は10秒待たずに別のサイトに移動します。アラートの観点からこれが意味することは、アプリケーションが完全に応答を停止したときに通知されるだけでは不十分だということです。稼働の監視は重要ですが、パフォーマンスの低下に関するアラートも受け取る必要があります。さらに、無応答アラートと区別できる必要があります。

アラートを微妙に調整

最新のアラート管理の課題は以上のようなものですが、ではどのように解決できるでしょうか。 答えはアラート管理プロセスを非常に柔軟に、より機敏にすることです。次のような戦略を採用します。

優先順位の高いアラートを目立つようにする

最も重大なアラートに迅速に対応するには、それが簡単に見分けられる必要があります。優先度の高いアラートと優先度の低いアラートがダッシュボード上で混在していると、双方を見分けるのは困難です。監視ソフトが優先度の高いアラートをマークすればはるかに簡単になります。

役に立たない警告を抑止する

役に立たないアラートを排除することで、ダッシュボードの視認性を向上させることができます。新しいユーザーアカウントの作成など、優先度の低いイベントのアラートを抑制することなどです。このようなアラートを完全に無効にするのではなく抑止する利点は、緊急の時は紛らわされず、かつ必要に応じて表示させることができるからです。

微妙なアラートの報告と抑制

抑制は必ずしも命題ではありません。特定の状況では特定の種類のアラートをいくつか抑制できますが、他の状況では抑制しないことを選択できます。

たとえば、就業時間内にスタッフがアカウントを作成しているときにはアカウント作成に関連するアラートを抑制し、時間外に行った場合はアラートを表示する、ということができます。または、再起動が一定時間内に3回以上行われない限り、サーバの再起動に関する警告を抑制したい場合もあります。

また、重複した対策やコミュニケーションを防ぐため、関連するアラート間の関連付けを作成することも重要です。

重要なイベントを見逃さずにアラートノイズを最小限に抑えるには、抑止、関連アラートのグループ化、通知閾値のカスタマイズなどを実行し、アラートの重要度をより洗練された方法で判定する必要があります。

アラートによって送信先を変える

すべてのアラートをチームの全員に送るのは非効率的です。異なるタイプのアラートは、各人のスキルとスケジュールに応じて異なるメンバーに送る必要があります。対応する者が異なるということは、アラートの柔軟な割り当てが重要だということです。次の1時間インシデント管理にあたるエキスパートは、その後は非番になるかもしれません。

最初から適切な人にアラートを送信するようにしておくことで、問題を判定してスタッフに割り当てるために必要な手作業の多くを省くことができます。

システムダウンだけではない監視

前述のように、アラート管理の成功は今日、障害だけでなくパフォーマンスの低下を検出することを意味します。このため、システムが容量の限界に近づいたとき（ネットワーク負荷が80％を超える場合や、アプリケーションのCPUタイムが閾値に達したが、まだそれを超えていない場合）にアラートを生成するように監視ソフトウェアを設定することが重要です。

もちろん、これらのアラートに重大な障害と同じ優先順位を付ける必要はありません。障害インシデントは、直ちに知り直ちに処理することがより重要になります。しかし、何かが完全に壊れるまで待ちたいとも思いません。代わりに、アラート処理を最適化して、パフォーマンスの問題がシステムダウンに発展する前に処理できるようにします。

DevOps時代には、インフラストラクチャはアジャイルです。アラート管理プロセスもそうあるべきです。すべてのアラートが同等の重要性を有すると仮定したり、すべてのアラートを報告したりレビューしたりする必要があるとした時代は終わりました。圧倒されることなく現在の複雑で変化の激しいインフラストラクチャを監視するには、アラートに対する最適化されたアプローチが必要です。アラートを重要度に応じて識別し解釈するIT組織の能力が試されます。

運用面での成熟は、いくつかの新しい ツール を実装したからといって一晩で起こるものではありません。核となるのは、より良いソフトウェアを提供するためみんながコミュニケーションのサイロを壊せるよう一丸となって文化を変える努力です。個別にツールがあるだけでは十分ではありませんが、スピードと精度を向上させ、コラボレーションを促進するようなオートメーションを適用すれば、ツールが大きな利益をもたらすようになります。

環境に合ったDevOpsツールは、チームの規模やニーズに応じて大きく異なる場合があります。あなたのツールチェーンを構築する方法には正解はありません。現実に、まず私たちが学び、模倣しようとしたいくつかの最良のワークフローやツールはNetflix、Etsy、Dropboxなどの革新的なチームが社内に構築したものだということを告白しておきましょう。

このリストの目的は、ソフトウェア配信ライフサイクルの各段階で最も人気のあるツールをいくつか共有することです。その一部は社内でも使っています。自分のチームのために適切なツールを評価する際にご参考になることを願っています。

計画

何をどうビルドするのか

リリースのすべての単一の依存関係と作業を計画しておくというウォーターフォール型のアプローチはDevOpsに反します。代わりに、アジャイルアプローチでは、ソフトウェアを小さな塊で構築してテストし、顧客のフィードバックを反復することで、リスクを減らし、可視性を向上させることができます。それが私たちを含む多くのチームが約2〜4週間のスプリントでの私たちがリリースを繰り返している理由です。

チームが各スプリントの開始時にアイデアや計画を共有しているので、以前のスプリントの反省からのフィードバックを考慮に入れてチームとサービスが継続的に改善されるようにします。ツールは学習やアイデアを計画に集中させるのに役立ちます。ブレーンストーミングプロセスを開始する際は、顧客リサーチデータ、機能要求、およびバグレポートをそれぞれ対象となる個人を特定し、その人にマップできます。このプロセスでは、物理的またはデジタルの付箋を使用して、共通のテーマをまとめてグループ化し、バックログのユーザーストーリーを構築しやすくします。ユーザーストーリーを特定のペルソナにマッピングすることで、提供される顧客価値に重点を置くことができます。アイデア段階の後、プロジェクトのバーンダウンと毎日のスプリントの進行状況を追跡するツール内のタスクを整理し、優先順位を付けます。

私たちが使っているツール：Active Collab、Pivo​​tal Tracker、VersionOne、Jira、Trello、StoriesOnBoardなど。

コード

いくつかのコードを書いた後に、ステージングに入る前に済ませる必要があることがいくつかあります。 コードをレビューして承認し、バージョンコントロールリポジトリのマスターブランチにマージし、必要に応じてローカルテストを実行します。

トップツール：Github、Bitbucket、Gerrit、GitLab

テストとビルド

今度はコードのビルド、テスト、およびリリースに関連するタスクの実行を自動化する時です。 ビルドが展開される前に、単体テスト、統合テスト、機能テスト、受入れテストなど、生産過程に完璧に押し込めることを確認するために、多数のテストを行う必要があります。 テストは、新しい変更が導入されたときに、コードベースの既存の部分が期待どおり確実に機能し続けるようにするための素晴らしい方法です。 新しいプルリクエストがあるときには自動的にテストを実行することが重要です。 これにより、手動による監視のために見落とされるエラーを最小限に抑え、信頼性の高いテストを実行するコストを削減し、早期にバグを面に出せます。

また、テストが完了したら、マスターの変更を自動的にピックアップし、依存関係のあるものをリポジトリからプルダウンして新しいパッケージを構築するなど、便利な機能を果たす多数の優れたオープンソースツールと有償ツールもあります。

トップツール：Jenkins、GoCD、Maven、CruiseControl、TravisCI、CircleCI

コンテナとスケジューラ

Dockerとコンテナの登場により、チームは新しい仮想化オペレーティングシステムをスピンアップすることなく、軽量で一貫した使い捨てのステージング＆開発環境を簡単にプロビジョニングできます。

コンテナは、アプリケーションをパッケージ化する方法を標準化し、記憶容量と柔軟性を向上させ、変更をより簡単にすることを容易にします。 これにより、アプリケーションをどこでも実行することができます。 言い換えれば、物事は、あなたがラップトップで変更を加えたときとまったく同じように、魔法のようにプロダクションで行動します。

トップツール：Docker、Kubernetes、Mesos、Nomad

構成管理

構成管理を使用すると、インフラストラクチャの変更を追跡し、システム構成の単一ソースを維持できます。 バージョン管理とイメージの複製を簡単に実行できるツール、つまりシステム、クラウドインスタンス、コンテナなどのスナップショットを撮ることができるツールを探してください。 ここでの目標は、標準化された環境と一貫した製品パフォーマンスを保証することです。 構成管理は、変更に起因する問題の識別にも役立ち、さらに容量が必要な場合に既存のサーバーを自動的に再現することでオートスケーリングをシンプルにします。

トップツール：Chef、Ansible、Puppet、SaltStack

リリース リリースの自動化

リリース自動化ツールを使用すると、本番環境に自動的にデプロイできます。 自動ロールバック、展開を開始する前にホストに成果物をコピーする機能などを備えた製品を選ぶべきであり、特に大規模な組織の場合は、サーバーインスタンスのスケールに合わせて、エージェントを簡単にインストールし、ファイアウォールを簡単に構成できるエージェントレスアーキテクチャが必要です。

テストに合格したものは、自動的にデプロイされることに注意してください。 ベストプラクティスは、最初に「カナリヤ」デプロイメントとしてインフラのサブセットに展開してみて、エラーが起きなければ全体に展開することです。

多くのチームでは、ボットを使って簡単なコマンドでデプロイするチャットベースのデプロイメントワークフローも使っているため、誰もが簡単にデプロイメントの活動を見たり、一緒に学習することができます。

トップツール：Bamboo、Puppet

デプロイメントを監視する

リリース用のダッシュボードとモニタをセットアップすると、リリースの進捗状況と要件のステータスをハイレベルで視覚化するのに役立ちます。 サービスが健全かどうか、導入前、導入中、導入後に異常があるかどうかを理解することも重要です。継続稼働している統合サーバー上で発生する重要なイベント、例えば失敗したビルドがあるとか、デプロイメントを中止またはロールバックするといった重要なイベントがリアルタイムで通知されること確認しておくことです。

トップツール：Datadog、Elastic Stack、PagerDuty

モニター サーバーの監視

サーバーの監視では、インフラストラクチャレベルのビューが提供されます。 多くのチームでは、ログの統合機能を使い特定の問題をドリルダウンしています。 このタイプの監視をすると、メトリック（メモリ、CPU、システム負荷の平均など）を統合でき、サーバーの健康状態を常に把握でき、アプリケーションが影響を受ける前に（そしてお客様がそれに気がつく前に）に問題に対処できるようになります。

トップツール：Datadog、AWS Cloudwatch、Splunk、Nagios、Pingdom、Solarwinds、Sensu

アプリケーションパフォーマンスの監視

アプリケーションパフォーマンスの監視では、Webサイトなどのアプリケーションやビジネスサービスのパフォーマンスと可用性をコードレベルで把握できます。 これにより、パフォーマンスメトリックを迅速に理解し、サービスSLAを満たすことが容易になります。

トップツール：New Relic、Dynatrace、AppDynamics

対応と学習 インシデント解決

監視ツールは豊富なデータを提供しますが、リアルタイムで問題に対して正しい行動をとることができる適切な人物にルーティングされないならそのデータは無駄になります。ダウンタイムを最小限に抑えるには、問題が検出されたときに適切な情報が通知され、トリアージおよび優先順位付けに関する明確なプロセスが確立されていることが大事で、それらによってようやく効率的なコラボレーションと解決が可能になります。

1分に数千ドルのコストがかかるようなアプリケーションとパフォーマンスの問題が起きた場合、適切な対応を調整することはしばしば非常にストレスですが、混乱することはありません。火事の最中に、連絡先の住所録を取り出して、コンファレンスブリッジに適切な人を選ぶ方法を探すのに30分も無駄にするのは望ましくありません。

PagerDutyはエンドツーエンドのインシデント対応プロセスを自動化して、主要な顧客に影響を与えるインシデントや日々の運用上の問題の解決にかける時間を削減できます。 PagerDuty社内では、エンジニアリングチーム、サポートチーム、セキュリティチーム、エグゼクティブなどみんなが、自社製品を使い、ITやビジネスの中断への対応策を調整して準備しています。柔軟性を持って私たちはオンコールのリソースを管理したり、実行不可能なものを止めたり、関連するコンテキストを統合したり、適切な人やビジネスのステークホルダーを動員したり、自社が推奨するツールと協働で対応にしたりしています。自分が戦闘中に何をどうに見たいかを簡単に設計できるとしたら、あなたももっと安心できるでしょう。

私たちが使っているツール：PagerDuty、HipChat、Slack、Conferencing tools

学び、改善する

対応が終われば、インシデントはプロセスとシステムをより弾力性を持って改善する方法を理解する重要な学習機会を提供します。 DevOpssのCAMS（文化、オートメーション、測定、共有の頭文字）の支えによって、インシデント対応とシステム性能のメトリクスを理解し、継続的な改善の目標に向けて、成功と失敗を共有するオープンな対話を促進することが重要です。

ポストモーティム（事後検証）の手順を合理化でき、解決すべき事項に関するアクション項目の優先順位付けを目的にポストモーティム分析を実行できるソリューションを探してください。あなたはきっと製品の使用状況や顧客からのフィードバックを理解するのに役立つツールを使い、ビジネス目標と顧客経験のメトリクスに関連するサービスがどのくらい成功しているか測定したいと思うでしょう。より良い製品とより幸せな顧客のために、システムと機能の両方の改善を正確に計画して優先順位を付けられるよう、すべてが次のスプリントに組み込まれるのです。

私たちが使っているツール：PagerDuty、Looker、Pendo、SurveyMonkey

繰り返しますが、ツールに投資するだけでは、モノリシックアーキテクチャーからマイクロサービスアーキテクチャに移行することはできません。また、セルフサービスのデプロイメントを1日に何回も実行できるチームは幻のままになります。 しかし、適切なツールとプロセスで新しい文化へのシフトを強化することで、ソフトウェア配信を最適化し、継続的に改善し、それを担当するすべての人の間でシームレスなコラボレーションと信頼を実現することができます。

以上を参考に、あなたのための適切なツールを探究し、見つけることに成功してほしいです！全員参加の機運を最大限に高めるために社内で使用すべきツールや、DevOpsのベストプラクティスを加速する方法について詳しく知りたい場合は、これらのリソースをご覧ください。

顧客は、価値観 を共有していると 感じる企業に忠実です。予期せぬ出来事が企業を襲ったとき、結果として生じた激動がブランドを危険にさらします。航空会社の災難や、テクノロジーシステムを巻き込んだ性能に関するインシデントなど、これらの瞬間は、顧客にサービスする能力を低下させることで、顧客体験に影響を与えます。顧客にブランドへのアクセスを提供するデジタルチャネルが増えている状況で、今日の現実は、世界中がポリシーや行動を監視する中で企業は事業を展開しているということです。

このシフトの影響から、CEOのオフィスにブランドが置かれるようになり、インシデント対応の中で企業のコミュニケーションを重視させる一因になりました。しかし、このチャレンジは企業のコミュニケーションのように、テクノロジー、製品、セキュリティなどのインシデント対応の共通部分にフォーカスする傾向があります。しかし、実際に問題となるのは、全ての側面がインシデント・オペレーションに書記から統合されていた場合、予期しない事態が発生したら、それらがどうに連携して最も効果的な戦略になりうるかです。

最近のForbesの記事で私たちは、危機の最中、特にインシデントのニュアンスが見落とされたときに、組織がブランドを保護するために使える3つのコミュニケーションのヒントを紹介しました。このような状況でストーリーラインをコントロールすることは、企業のコミュニケーションの責任です。彼らの役割は、オペレーションと顧客との関わり方を変えられるコミュニケーション計画を準備し実行することです。企業のコミュニケーションがインシデント対応業務に合わせて準備されている場合、次の点に対応できるメリットがあります。

出血を遅らせる

重大インシデントでは、技術とセキュリティの関係者だけが含まれる古典的な対応チームが組織されることがよくあります。 専門家が問題を特定して解決する間に、企業のコミュニケーションチームは待機させられ、対応作業に遅れをとります。 その一方で、デジタルチャネルを横断して世論が醸成され、形成されています。 レポーターは複数のストーリーを公開し、コミュニティ、ユーザー、パートナーはソーシャルチャネルを通じて意見を共有しています。インシデントの進展に合わせて企業のコミュニケーションチームを早期に巻き込むことで、危機に瀕しているブランドの出血を遅らせる機会が得られます。

ブランドの再構築

ポストモーティム（事後検証）のフェーズでは、重大インシデントに巻き込まれたビジネス全体の関係者が集まり、何が起こったのか、どのように対応業務が実行されたのか、何が改善できるのかを議論します。事態が終息すると、企業のコミュニケーションチームは、顧客やコミュニティの信頼を回復するために組織の舞台裏で働きます。彼らは企業側のメッセージを次にどこへ届けるかを決定し、PRの機会として何をすべきか、あるいは何をしないべきかを決定するために良い判断を下します。危機後に各ブランドは顧客の評判を素早く回復するためにどれだけのケアと行動を取ったかを顧客に迅速に伝えます。時には、整合性が取れない行動に直面したり、次の関連イベントが発生したりして、バックファイアを食らうことがあります。

デジタル時代には、企業の運営方法やコミュニケーションの役割に対する期待が急速に高まっています。新しい技術が登場し、デジタルチャネルが増加する現在、重大インシデントへ対応するための運用の初期段階でコミュニケーションを統合しておくことが、お客様のブランドが世間から否定されず称賛されるという差を生み出します。

典型的な技術者はたった1つの質問ですべての課題に対峙します：「私は自分でこの ソリューションを構築できるだろうか？」と。そしてこの質問は重要な考察が得られるので十分考えるに値します。 では私たちは作るべきですか？買うべきですか？ インシデント管理ソリューションの評価は今この問題を招いているようです。 しかし、今インシデント管理プラットフォームを作るべきか、あるいは購入するべきかは、どう分かるのでしょうか？

なぜビルドするの？

独自のソリューションを構築したいという願望が、商用ソリューションの調達権限があなたにないという単純な理由によることもあります。 例えばエンタープライズのITにはツールの予算があっても、DevOpsチームがそれを必要としていたりします。 オープンソースプロジェクトを基にソリューションを構築する方が、商用ソリューションを購入するのに必要な長い駆け引きをするより簡単に思えるかもしれません。 しかし、これは組織的な問題であって、技術的な問題ではありません。 そしてカスタムビルドのソリューションは短命になることがよくあります。

でも独自のソリューションを構築する理由は他にもあります。

現実のまたは既に必要が見えている固有の要件がある

セキュリティとプライバシーに関する懸念がある

コスト

これらは、インシデント管理ソリューションの構築を検討する正当な理由ですが、どれも精査する必要があります。

あなたの要件は本当にユニークですか？ これが当てはまるかどうかを特定する方法は、競合他社と彼らが使っているものを見て、さらに類似の組織と比較して要件を調査することです。同時に、独自の要件があっても、なぜそれがユニークであるのか疑問に思うかもしれません。それって本当に必要なの？と。

セキュリティに関しては、商業的なインシデント管理を使わないようにさせるようなセキュリティとプライバシー上の懸念は何ですか？データが暴露される可能性がありますか？ほとんどの場合、アプリケーションのデータはアラートの中に含める必要はありませんが、そうなっている場合は、検討する必要があります。一般的なセキュリティに懸念があるのなら、ベンダーは自らが常にセキュリティの脅威に敏感であろうと努めていることを知っておいてください。多くの場合彼らはあなたの社内の運用チームよりもセキュリティの面ではるかに優れた能力を持っています。

そして、コストの問題があります。 独自のソリューションを構築する上で最もコストのかかる側面は簡単には数字にならないため、コストの計算は難しいのです。インシデント管理サービスの月額料金と、フルタイムの開発者による一回きりの開発のコストを計算するのは簡単です。しかし、継続的なメンテナンス、機能の変更、および大きな一回切りの開発のコストを予期することは困難です。このソリューションを構築していない場合に、開発者は何をしているんでしょうか？また、開発中に複数のプロジェクトやバックログを脇に置いてしまうコストはいくらですか？構築した人が退社した場合に別の問題が発生します。残されたコードベースを理解するためにまたコストがかかります。組織のインフラストラクチャのミッションクリティカルな部分に関連している場合、知識を持つ人が組織を離れることは望ましくありません。

インテグレー？

インシデント管理ソリューションの構築には、1つに大きな弱点があります。成功したインシデント管理プラットフォームには、ソース（アプリケーションとインフラストラクチャなど）とディストリビューション（コラボレーションツールなど）への統合に関する膨大なライブラリが用意されています。これらの統合を実現するためには開発者は新しいAPIに対して習得し、構築する必要があり、かなりの時間がかかります。独自のインシデント管理プラットフォームを構築する組織は、いろいろなユースケースをサポートする必要がなく、重要な統合を行うだけで済みます。

しかし、これらのシステムのAPIが変更されると、あなたは盲目になる可能性があります。新しい機能を使えず、プラットフォームを完全に壊す可能性があります。オープンソースプロジェクトは、統合の中での変化に、あるいは新しいものを作リ出すために素早く対応することはありません。何か不具合が生じた場合も、開発者はもう別の何かを抱えています。もちろん、インシデント管理システムと統合する必要のあるツールの選択は、チームの規模の拡大とそのニーズの変化に伴って変化する可能性があります。

ビルドする時期

オープンソースプロジェクトを基盤とするカスタムインシデント管理プラットフォームが有用なシナリオがあります。それは特定の目的のためのビルドが必要という、とてもニッチなシナリオです。一般的に、このようなソリューションが必要な組織は、グローバルでの商業的インシデント管理を行っており、ニッチなシナリオのためにインシデント管理プラットフォームのAPIに統合していることさえあります。

もう1つの目的は、アプリケーションまたはインフラストラクチャのサポートとは異なるコンテキストで使用されるアラートのためです。おそらくそのアラートはコラボレーションや製品管理に使用されています。このような場合は、自社で作った他のユースケース向けの責任の低いシステムと、商用およびミッションクリティカルなインシデント管理システムとそのユースケースを分けたほうが有用な場合があります。アプリケーションの使用方法から学ぶことについては同じことが、すでに多くのカスタマイズを行っているチームにも当てはまります。例えば、新しい機能がローンチされたときに、その機能が使用されたらアラートを受け取るということができます。また、新しいインフラストラクチャが配備されたときに、パフォーマンスを示す特定のKPIにヒットしたときにアラートを表示させるように設定することもできます。

もう1つの理由は、内外へのデータ漏えいの懸念がある場合です。例えば、是正措置が個人を識別できる情報を、内部のティア1のサポートに、その人たちには見る権限がないのに晒してしまうアラートです。これは問題であり、特に規制産業では問題となる可能性があります。 ほとんどの場合あなたはプラットフォームでの役割と見られる内容を変更できるため、これは問題にはなりません。一般的に言って、あなたはそれを常に試すようにするべきです。避けられない場合もまれにはあるでしょう。

あなたの輝く時間が来る

熟練した技術者は、自分の興味の範囲を超えて、いつビルドや購入をするのが適切かを判断し問題を解決できるようになります。このソリューションは早速作り始めるべきで、立ち止っていてはいけません。これはカスタムソリューションに伴う長期的なサポートであり、リスクです。ソリューションの作成だけでなく、実行する必要もあります。インシデント管理システムにインシデント管理システムをインストールしているんですか？他の何かの稼働時間を心配することはストレスであり、インシデント管理がダウンすると、何も見えなくなります。

コードベースとインフラストラクチャへのカスタムニッチの統合を理由に、独自のインシデント管理ソリューションを構築することが正当化されることがあります。あるいは、商用インシデント管理と連動する非ミッションクリティカルなユースケースがある場合は、独自のインシデント管理を構築する価値があります。しかし、一般的に商用ソリューションの総所有コスト（TCO）は低く、規模の拡大に合わせてニーズに対応し、特定の専門家が退職したときにツールやプロセスが破壊されないようにし、キュリティとプライバシーに関する懸念にもより良いカバレッジとソリューションを提供します。

ビルドや購入を決定するときは、機会費用に重点を置くことをお勧めします。これはあまり知られていない費用ですが、これを考えると普通はかなり早く答えがはっきりします。