Blog
ブログ

2018年3月12日  (更新日:2022年3月9日)

HashiCorp Consulインテグレーションガイドを追加しました

HashiCorp Consulは、インフラ内にあるサービスを検出および設定できるようにするサービスで、高可用性をもたらす分散型システムを構築するために利用できるサービスです。複数のデータセンターに分散するシステムを構築・管理できます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2017年12月31日  (更新日:2022年3月9日)

コンピューターの使い方:最先端のインフラストラクチャーの様相はどう変わったか

今日のインフラストラクチャ はあなたの祖父母の時代の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つにあげられます。また、仮想化されたコンピューティングと、バーチャルリアリティと、昔からの物理的な経験の区別が崩壊する可能性があります。多くの点で、今日のコンピューティングの変化の速度は、私たちの能力によって制限されています。つまり変化が発生したときにそれを私たちが吸収し、発達するにつれてその力をフルに活用する能力によって制限されています。しかし、自動化とインテリジェンス機能は、垂直でもドメインでもほぼ全ての機能を破壊的に変え、効率性の新たな可能性を広げ、人々の作業の焦点を劇的に変える可能性があります。

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

続きを読む
ベストプラクティス
2018年2月19日  (更新日:2022年3月9日)

Composeインテグレーションガイドを追加しました

Composeは、プロダクション対応のオートスケーリングMongoDBやElasticsearchを提供するデータベースサービスです。Compose のコンポーネントは、データベースの状態の変更やパフォーマンスの問題を通知するMongoDBイベントのアラートを提供しています。ComposeはすべてのアラートをPagerDutyに配信し、ユーザーはエスカレーションポリシーと決められた連絡方法に従って通知を受けます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2017年12月23日  (更新日:2022年3月9日)

インシデント発生時のベストなコミュニケーションの方法

あらゆるビジネスが デジタルビジネス に進化し、ほんの少しの停止時間でも、これまで以上に収益とブランド価値に深刻な影響を与えるようになり、危機に直面した際の効果的なコミュニケーションの必要性が増してきました。これによりサービスを開発・管理する技術チームにより高いプレッシャーがかかっているということですが、さらにデジタルトランスフォームは、ブランドの評判と顧客体験に責任を持つ他の事業部門にもプレッシャーをかけています。

製品やサービスから顧客が最大の価値を引き出せるようにする責任を負うコミュニケーション、マーケティング、とりわけサポートチームを見てみましょう。プレッシャーによって渉外機能に新しいワークフローとベストプラクティスが必要になっています。PagerDutyで私たちが学んだ実践から、これまでに磨いてきた4つのベストプラクティスを紹介します。

  1. みんながオンコール担当

PagerDutyのコミュニケーションチームの一員として、私は技術担当の同僚や他の多くの人と一緒にオンコールの仕事に従事しています。受け取るインシデント通知のほんの一部を見ても、なぜ自動化とインシデント対応プロセスを持つことがスムースな運用に必要なのかを深く理解しています。それが今日のデジタルサービスをうまく稼働させているのです。何かが顧客にインパクトを与えるとき、コミュニケーションチームやサポート、営業、法務、そしてリーダーなど他の部門の関係者は、私たちが顧客と適切なコミュニケーション対応をプロアクティブに取れること、そして時が経つ間に自らのブランドと顧客の約束を守るために正しい対応を効果的にやれるのだということを、知っておく必要があります。

2.サポートと足並みをそろえる

受賞経験のある当社のサポートチームは重大インシデントに遭遇したときには顧客対応の最前線に立ちます。しかしコミュニケーションチームは次のことを理解するために整列して待機しています。

どんなインシデントでなぜそれが起きたのか? どのくらい多くの顧客がどのくらい長く影響を受けているのか? インシデント対応はどのくらい進んでいるのか(まだ調査中なのか解決に近づいているのか)?

インシデント対応プロセスの中では、チームは顧客との連絡窓口(注:カスタマーリエゾン)を必要とします。その窓口担当は、アプリやサービスに起きている障害がさらに悪くなりそうな時に外部と最善の方法でコミュニケーションをとれるよう訓練されている人たちです。

私たちのコミュニケーションチームは、今何が起きていてどんな影響があるのかを正確に理解するために、カスタマーリエゾンと一緒に作業をします。PagerDutyの中では、インシデントに関するSlackチャネルの一部に加え、Stakeholder Engagementという機能で情報の更新を自動化しています。我々は各チームからより抜かれた適切な人の間で協業が進むようタイトなラインを作り、顧客やより広い市場との有益なコミュニケーションが作れるように協力しています。

3.プロアクティブになろう

伝統的なチケットやITSMのワークフローを使っている場合、プロアクティブになる機会を失っているかもしれません。顧客は何か悪いことが起きるのをあなたより前に知ります。例えばソーシャルメディアなどの公開の場やニュースで彼らが気づく前にあなたが問題を修復する機会はないでしょう。コミュニケーション対応の観点からは、外向けに出すメッセージをより早く作れるよう行動するべきです。そうすれば不満のツイートや正しい情報を求める記者からの電話に対応できるようになります。インシデント対応コミュニケーションのこの段階では、傷ついた評判を修復する戦略を立てることが大事であり、理想的には事態を正常化するためにリアルタイムに起きていることを共有すべきです。プロアクティブなコミュニケーションを支援するため、我々は発生しうる危機のシナリオを特定してワークフローを作り、さらにこれまでの経験に基づいて、使うべき言葉を中心に、ベストプラクティスを作成しました。もちろん、危機シナリオは独自のものですが、平和な時に基礎を作っておけば、余裕がなくとストレスが高い戦闘中でも、素早く行動できます。

4.ブランドをリシェイプする

インシデントが解決してもコミュニケーションチームの仕事は終わりません。理想的なインシデント管理のライフサイクルの中で、重大インシデントは必ず事後検証を受けるのです。その中では関係者全員が、何が起こったのか、その対応がどう実行されたのか、今後どのように改善できるのかを議論します。これは学習と改善のための時間です。コミュニケーションチームにとしては、組織全体で協力し顧客や広範なコミュニティの信頼を回復する計画を策定し実行する必要があります。つまり当社のブランドが期待に応えられなかった部分を改善する戦略を実行するのだと考えてもらってよいでしょう。企業としての表明も改訂し、健全な判断を使い今後どうするのかを検討しないといけないでしょう。これはまた、あなたががビジネスに携わっている理由と言行一致を確約するための時間でもあります。ビジネス全体での行動が間違いを正すために必要かもしれません。

今日の、”マイクロ秒単位の時間”に支配され、常時オンが当たり前の世界で成功するためには、コミュニケーションチームは他のチームと一緒にデジタルオペレーションのエクセレンスの追及に”レーザーフォーカス”しなければなりません。これは、これまでと違う覚醒を意味するだけでなく、法外に優れた顧客体験を提供することを心の中の統一目標として、各機能部門を横串した新しい作業とコラボレーションのやり方を意味します。

続きを読む
ベストプラクティス
2018年4月9日  (更新日:2022年3月9日)

Circonus Integrationガイドを追加しました

Circonusはホスト、SaaSの双方を監視するシステムとして、種々のメトリック(システム、ネットワーク、アプリケーション、さらにはビジネスメトリックまで)を収集し、トレンド分析と障害検出を実行します。CirconusのアラートをPagerDutyに送信することで、PagerDutyのアラート機能をフルに活用できます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2017年12月29日  (更新日:2022年3月9日)

DevOpsの効率を上げるため適切なツールを選択する

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

環境に合った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のベストプラクティスを加速する方法について詳しく知りたい場合は、これらのリソースをご覧ください。

続きを読む
ベストプラクティス
2017年12月23日  (更新日:2022年3月9日)    |    DevOps

ChatOps:チャットボットがインシデントを引き受けます

あなたの考えていることをずっと追いかけていて、あなたの計画の実行を助ける、そんな小さな ロボット があったら素晴らしいでしょう。もし、あなたがインシデント監視インフラストラクチャを担当する管理者なら、それは存在します。チャットボットと呼ばれる彼らは、インシデント管理ワークフローを最適化するための鍵です。

ここではチャットボットとChatOpsを使うのが、DevOps手法を採用している組織にとってとても重要な理由について説明します。

チャットボットの定義

「チャットボット」は人によって異なるものを意味します。大まかに定義すると、チャットボットは、人間と「会話」をするプログラムです。チャットボットはずいぶん昔から存在しています。あなたがAOL(注:America Online)がまだインターネットを支配していた時代に育ったなら、例えばSmarterChildというAIMインスタントメッセージングサービスのためのチャットボットを覚えているでしょう。

インシデント管理とインフラストラクチャの監視の分野でいうチャットボットは、もっと狭い意味を持ちます。彼らは人間の言うことを理解し会話をするだけでなく、人の代わりにアラートを監視しインシデントに対応します。

言い換えれば、この意味でのチャットボットは、SlackやHipChatなどのコミュニケーションプラットフォームと統合され、人間の入力に応答してコマンドを処理するプログラムです。コマンド自体は、多くの場合、バックグラウンドで動作するサーバで実行されていますが、管理者が行う必要があるのは、何をするかチャットボットを教えることだけで、残りは事前に定義された手順に基づいて自動的に処理されます。

チャットボットとChatOps

チャットボットは開発業務におけるツール、プラットフォームであり、ChatOpsと呼ばれます。彼らは開発者と運用チームに以下のような利益をもたらします。

コマンドを実行するための便利なインタフェースを提供する

すでにSlack、HipChatや他のコミュニケーションプラットフォームをすでに使っている場合、なぜコマンドを実行するために異なるインタフェースに乗り換えるのでしょうか。チャットボットならばあなたがコマンドを実行する必要はありません。チャットインターフェイスから直接実行させることができるので、ずっと素早く実行できます。

チーム全体を可視化

あなたがチャットボットとの対話を公開していれば、参加するすべての人があなたが実行したコマンドを確認することができます。これは、あなたのチーム全体を可視化し、チームメンバーが同じコマンドや矛盾したコマンドを実行していないことを確認できます。そして同時に、チーム全体が学習する機会も提供します。

リアルタイムなアクションを促進

伝統的に、チームは集まり、計画を立て、別れて、実行します。チャットボットとChatOpsを使うと、コミュニケーションと操作インターフェースが統合されているので、対話と実行が同時に可能です。重要なオペレーションを実行する前、計画を立てるための時間が要らないとは言いませんが、例えばインフラの障害に対応しているときのように時間が最重要である場合、計画とオペレーションが同時に行えるのは大きな利点です。

チャットボットとChatOps、DevOpsチーム

これらの利点は、ほぼすべてのタイプの組織に有用です。組織がDevOpsチームスタイルのワークフローに移行しつつある現在、これは特に重要だといえるでしょう。

それはなぜか。DevOpsチームの2つの原則は、シームレスなコミュニケーションとオペレーションの俊敏性であるためです。ソフトウェアの継続的デリバリー(と透明性と公開性)を求める場合は、チームメンバー間のコミュニケーションギャップを回避する必要があります。また、インシデント対応時に継続的デリバリーのパイプラインを壊さぬよう、迅速かつ容易に行動できる必要があります。

同じ論理は、監視とインシデント管理にも適用されます。監視チームを継続的に活動できるようにしたい場合、リアルタイムでインシデントを特定し解決するため、瞬時に可視化されたコミュニケーションが可能な手段が必要です。素早いアクションと効率的かつ協調的な方法でチームメンバー間に責任を持たせるための方法です。チャットボットはこのすべてを可能にします。そのため、チャットロボットはDevOpsの世界を席捲しているのです。

2017年12月30日  (更新日:2022年3月9日)    |    ベストプラクティス

ChaosCat:PagerDutyでのフォルトインジェクションの自動化

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

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

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

2018年3月9日  (更新日:2022年3月9日)    |    インテグレーション&ガイド

Catchpoint インテグレーションガイドを追加しました

Catchpointを使用すると、オンラインアプリケーションのパフォーマンスを管理、監視、テストできます。 PagerDutyをCatchpointとインテグレーションすることにより効率的な監視サービスを実現します。

詳しくはこちら

2018年1月18日  (更新日:2022年3月9日)    |    ベストプラクティス

スケーラブルな分散システムを構築する

予防は最高の薬です

分散システムを構築する最善の方法は、 分散を避けることです。その理由は簡単で、分散コンピューティングの欠陥を迂回することができます(一部の楽観主義者の考えとは異なり、分散コンピューティングの欠陥はまだ残っています)。

私の個人用のラップトップにはSignalFXのステッカーが はってあります。これは、さまざまなトランスポートメカニズムの速度のリストです。そもそもこのステッカーは、特にデータセンター間を移動するときに、複数のディスクやネットワークを使うのを避けるようにと言っています。それに従い、機械的な共感を抱くならば、単一ノード上で毎秒何百万件ものトランザクションを実行できる取引プラットフォームをサポートできる、LMAXのように市場を破壊するような素晴らしいものを構築することができます。メモリや単一のマシン上で処理させるようにするとさらに多くの処理ができます。おそらく15秒分の作業をやり直しても問題ない場合は、メモリ内ですべての作業を行い、1分に4回チェックポイントをディスクに書き出すだけです。そのようなシステムは非常に高速に動作し、完全にスケールアウトするという問題を回避できます。

自分自身をだますことはできません – 分散システムは常に複雑さを増し、生産性を低下させます。もし誰かが別のことを言うのなら、その連中はおそらくいんちきなものを売っているのでしょう。

なぜそうしているのかを調べ、前提をすべて問い直してください

「高可用性」と呼ばれる要件のせいで、すべてのコードを1つのノードに置くことが不可能になります。この要件は、しばしば、複数のシステムが引き込まれるまで非常に高価なステップを引き起こします。ここでは、2つの要件、チャレンジの仮定とチャレンジの要件があります。この特定のシステムには本当にファイブナイン(訳注:99.999%)の可用性が必要ですか、それとももっと 緩い可用性を与えるレイヤーに移行できますか?特にあなたのソフトウェアがそれ自体を証明する必要や、HA(高可用性)やその他の鐘や笛を鳴らす必要があるのならば、成熟度の低い最適化を施してしまう可能性があります。そうではなく、今すぐにスキップして、市場投入を早め、後で追加する戦略を立ててください。ビジネスのステークホルダーが「はい」と言うなら、「HA」にする必要がありますが、トレードオフと、時間とお金を使う実際には使えないものに時間とお金を費やすことになるかもしてないことを相手が知っていることを確認する必要があります(顧客がその製品や機能を気に入らないようになるという結果も考えられます。顧客が好きになることを知っている製品や機能だけを作ってればリスクはなく、あなたが始めたベンチャーは退屈な雲の上に止まってしまいますが)。

CAPの定理を説明すると利害関係者に、可用性や一貫性を持たせられるということは言えますが、両立は無理です(もう一度言っておくと、楽観主義者の中にはそれは問題ないという人がいますが、間違っていると思います)。 たとえば、通知を送るシステムを構築した場合、たいていは、一貫して通知を送るシステム(一貫性がありますが可用性の低い通知)とか、ほとんど常に通知を送理続けるシステム(可用性はある一貫性が低い)を作ることはできます。 通常、最終的に一貫性のある(AP)システムは、調整が少なくてすむため、構築が楽で、拡張と操作が簡単です。可用性の要件を取り除けるかどうかを検討してみてください。 普通は、APソリューションで問題解決を図ることを検討することは価値がありますので。

忘れないで – 何かを避けられないなら、少なくとも単純にする方向で交渉してください。 複雑な分散システムを実装しないことが、分散システムを構築する最善の方法です。

人生をシンプルにする

複雑さは我々の商売の敵なので、どんなコードを書いていても、どのようなシステムを設計していても、この「複雑さが膨れ上がったらハンマーで叩き潰す」というモグラ叩きゲームをプレーする必要があります。 複数のシステムにまたがるソフトウェアを書いたらすぐにこれはさらに大事になります。分散システムは本質的に複雑なので、偶発的に複雑さが増すことには我慢しないようにしてください。分散システムの中には、他のものより実装が簡単なものがいくつかあります。単純なものに固執し続けることです。

HA用に配布する

可用性を向上させるにはいくつかの方法があります。ノードのクラスタを作り、すべてを調整できます(作業状態を常に保存しておくと、どのノードでもなんでも拾えるようになります)が、それには多くの調整が必要です。 調整はシステムを壊れやすくするので、おそらく維持できないのではないでしょうか。 コーディネーションを避けるためのさまざまな選択肢があり、依然として優れた可用性を保てます。

同じ作業を複数のシステムで並行処理させ、1つのシステムの出力のみを使うこと。 すべてがセカンダリノードにレプリケートされるため、プライマリノードに障害が発生すると、レプリケーションによってバックアップノードが確実に「ホット」になり、瞬間的に引き継ぐことができます。調整が必要なのは最初にどのノードを実行し、どのノードを2次バックアップにするかを決めることだけです。 予備の待機系を持つこと。 プライマリノードは定期的に共有ストレージ上で作業を継続し、作業が停止すると、セカンダリがそれを読み込んで引き継ぎます。 ここでの調整は、通常、テイクオーバーが必要かどうかを知るために、常にセカンダリがプライマリを監視するようにしておくことです。

どちらの場合も、調整の単位は「トランザクションごと」から「構成ごと」に移行します。分散した作業トランザクションの扱いは難しいので、構成レベルの調整を取り除くことができれば、そうしてください。しばしば、これにはいくつかの作業が含まれます。「正確に1つ」の作業プロセスは、マシンが死ななければ「ほとんど正確に1つ」のプロセスになり、何も見逃さなかったことを確実にするためには最後の1分まで再生してみる必要があります。場合によっては、重複したオペレーションが表示されるのを避けることはできませんし、要件に関してステークホルダーとチャットする必要があります。正直なリスクアセスメント(1年に何回くらいそのマシン群は死ぬのか)と、正直なインパクトアセスメント(どのくらい各要素が重複する作業をしたのかと、ユーザーにどのくらい不便を感じさせたのか)と正直な難易度アセスメント(ぜい弱性を生じさせ、これにより可用性が低下するような余分な作業と複雑さがどれくらい増えたか)を実施しましょう。

場合によっては、データセンターに障害が発生した場合にも可用性が必要になることがあります。そのような場合には注意が必要です。システムが脆く、早くなりすぎるので、最小限の調整で済むようにしたいと考えるようになるでしょう。

パフォーマンスのために分散させる

一つのノードだけですべての作業を完了させることはできない場合もあります。まず、そんなポジションをとらないようにしてください。目をしっかり開いて、サイクルを無駄に使っているところを探してください。LMAXの人々は、1台のマシンで1秒あたり7桁のトランザクションを実行できることを示しました。より大きなインスタンスが必要ならAmazonを使うべきでしょう。私はまともなソフトウェアとは、より速いハードウェアを手に入れれば迅速に修正できるようなマルチコア対応のものだと、今のところは思っています。より多くのコアでより速く実行できるようにコードを書けない場合は、たぶんノードを追加しても高速化は期待できないのではないでしょうか? LMAXレベルのエンジニアリングがなくても、少なくとも1秒あたり5桁のビジネスオペレーションをソフトウェアが処理できると問題を解決するためにマシンを追加する必要がある場合(これは大きな問題です)、調整が最小限になるように計画してください。

想定してよいと思います。 1ノードでは1秒間に数百個も処理できないのでスケールアウトしたい、というのなら、最初の設計をしたボードに戻ってください。おそらく、あなたのコードには対処が必要な別の問題があるのです。

問題を解決するためにマシンを追加する必要がある場合(これは大きな問題です)、調整が最小限になるように計画してください。

トランザクションの調整ではなく構成の調整をする。さらなる協調の必要なしに各ノードがそれ自身のチャンクをプロセスに実行させるための調整スキームをノードに使わせます。あるノードが使えなくなったときに各ノードが再配布できるようにすれば、HAを非常に簡単に追加できます。 どんな調整も全く必要としないように、並行できる作業を見つけること。 ステートレスなWebサーバーが良い例としてここに挙げられますが、調整されていないノードの束を投入できるのはそこだけに限りません。

ストレージは安いのだから活用しよう

コマンド/クエリ分離やイベントソーシングなどのアーキテクチャパターンは、データストレージを複数の特殊なステージにデカップリングし、複製することがよくあります。これらの特殊なステージは、分散設計をサポートするためにはうまくいきます。ローカルに保存するものと分散するものを選択できるため、調整を最小限に抑えるハイブリッドソリューションになるからです。たとえば、アップデートコマンドを分散Kafkaクラスタに書き込むことはできますが、そこからの下流のすべてはローカルで操作できます(たとえば、コンシューマがアップデートコマンドを処理し、クエリに使用されるElasticSearchノードを個別に更新します)。 「実際の」データは、利用可能性が高く、メッセージストリームで調整されます。システムは、検索、分析などの特殊な処理のためにそのデータのビューを使用します。このようなシステムは、中央のデータベースシステムがすべての操作のネクサスであり、必然的にボトルネックになる古典的な構成(データベースシステムがスケーラビリティのために構築されたものであろうとなかろうと)よりも簡単に維持できます。

データを冗長に保存し、複数の独立したシステムがそれぞれ独自の最適化された形式のデータを使用するようにしてください。そうすれば調整の必要性が低くなり、最終的にはストレージコストは比較的小さな増加で済むようになります。

NIH症候群を避ける-車輪はすでに他の場所で再発明されている

Googleのスケールでシステムを運用するのでない限り、分散型であなたが実装しようと取り組んでいるシステムは、一から自分で構築する必要があるほど特別なものではないはずです。あなたが投資をしているのはビジネス上の問題を解決するためであって、ツールやインフラストラクチャを構築するためではないでしょうから、2017年の今、自分のための特別な何かを探す理由はないのです。分散システムを正しく実装するのは難しいので、失敗する可能性が高いのです(パーシステンスと暗号化についても同じアドバイスができます)。独自の問題を抱えていて自分自身で何かを発明する必要があると思っている場合は、実はちゃんとじっくり世間を見ていないか、何百ものオープンソースプロジェクトのどれかが使える形に、自分の問題を定義し直す努力をしていない可能性があります。あなたは「ビジネス」を推進しており、分散ソリューションをずっと簡単に、したがって信頼性を高める形で要件の形を変えるのを助けています。あなたが抱えている問題の、ユニークではない部分を解決するための、正しいソフトウェアを見つけましょう。そうすればあなたは自分の会社を特別なものにすることに集中できるようになります。

そう、ツールを作ること(tool-smithing)は楽しい – 私も大好きで、一日中やっていても飽きません。そして、確かに、独特の雪のかけらみたいに見えるような形であなたの問題をフレーミングすることは、自尊心のためには良いことです。でもそれは辞めて、ビジネスを成功に導くために本当の問題を解決してください。

2018年1月22日  (更新日:2022年3月9日)    |    ベストプラクティス

DevOpsカルチャーを構築するためのガイド

DevOpsを知った時期によって、DevOpsの実装方法に関する認識は変わります。DevOpsはまず文化のみの動きとして始まり、成熟するにつれてますます戦術的になりました。

文化がDevOps環境の中心にあります。 多くの場合、文化はDevOpsにとって最も難しい部分です。また、DevOpsの文化を構築するための万能薬はありませんが、私が以下で説明するように、働いている組織の種類に無関係に、健全な文化を定着させるのに役立ついくつかのテクニックがあります。

なぜ文化が大事?

文化という言葉はお嫌いかもしれませんし、大好きかもしれませんが、それは問題ではありません。文化に関してそういうことは環境に関係なく常にあるものだからです。 文化が意識されていない開発環境では、それ自体が有機的に作成されますが、これは通常、あまり望ましくないシナリオになります。 それは独裁国家(fiefdoms)の文化、あるいはすべてが壊れやすく、すべての新機能はそれが書かれる前でさえ失敗とみなされる、恐怖の文化かも知れません。。

だから、どんな場合でも文化があります。 DevOpsの原則が作ろうとしているのは、意図的に作られた文化です。組織は、その目的を最もよく支える文化を事前に決定し、その枠組みを確立し、向上させ、維持するために必要なことを行います。

DevOpsの文化が悪い印象を持たれているのは、それはしばしばヒップスターやスタートアップに関連する言葉だからです。 しかし、これは正確ではありません。その文化の要素のいくらかはスタートアップのロビーに属するように見えますが、DevOpsを意図的に文化として広げようとする触媒はボトルネックを避けられるかもという希望でした。あらゆる種類のプロセスとツールを採用してより速く開発を進められるはずですが、意思決定に加わっていないユーザーにより速度が制限されると、高品質でより頻繁で高速なリリースは実現できません。

文化の問題のもう一つの理由は、DevOpsは単なるプロセスやツールではないからです。 これは、DevOpsに対応しないスタティックな環境にデリバリーチェーンがならないようにすることを目的に、作られています。プロセスとツールだけで開発運用を「実装する」場合、2年後にはその環境はウォーターフォールのようなルック&フィールになり、現在の開発の標準に追いつけなくなります。

文化を快適にする

適切な文化を醸成することは、組織が、「より良いソフトウェアの品質とスピードを促進する文化をサポートし成長させる必要がある」と認めているほど簡単です。、いくつかの明確な目標を持ちどう行うべきかを意識し始めると、すべてのチームメンバーにとってその文化が最優先事項になります。 彼らは新しいツールを採用する際に、ツールがどのようにモジュール化でき、スクリプト化できるかを考えます。 あるいは、他のチームメンバーとのコミュニケーションについて考えるとき、彼らは簡潔に結果が得られることに重点を置くでしょう。チームがポジティブな文化を築くためにできることは、組織がより良いコードの文化に専念していることを明確にすることに加えて、他にもいくつかあります。

管理責任を持つこと(独裁ではなく)。 あなたが欲しい、または必要とする文化は、トップダウンでの導入を必要とします。でもそれは指示されるべきではありません。文化を支えるために、チームメンバー(リーダーシップとエグゼクティブの両方を含む)は、人々にどのように行動すべきかを伝えるのではなく、文化を積極的に実践してメリットを見せる必要があります。 あなたは誰かにチームプレーヤーであることを伝えることはできません。チームプレーヤーであるという利点を示す必要があります。 しかし、これは、誰かがその環境内に収まらない場合、彼らが歩き回っても良いようにするか、組織から去らせることで収拾する必要があることを意味します。 成功を分かち合うこと。 チームがそのメリットを理解するためには、リリース頻度の増加、欠陥の減少、人間の関与を必要としないタスクやリリースが増えるといった成功を共有する必要があります。チームの全員がより効率的な環境のメリットを享受できるわけではないので、そのメリット(革新的なビジネスの差別化要因の企画や繰り返しの少ないタスク、バーンアウトの削減などに専念する時間)を、常にチーム全体で話し合う必要があります。 チームを小さくする**。 強い文化を維持するには、より小さくて緊密なチームに保つことです。 これは階層の問題であり、リーダーシップは絶対に関与する必要があります。 アマゾンのようなハイテク企業の指針は、すべてのチームが「ピザ2枚で足りる」少人数のチームでなければならないということです。すべてのメンバーがチームへの貢献度を明確に把握し、作業の可視性を確認する必要があります。 これは、各チームが協力して文化を維持し、直接的な説明責任を持つようにするのに役立ちます。 目的をシェアする**。 組織がしばしば間違っている点は、競合する目標を設定することです。 チームメンバーが常にある測定方法で評価されながら作業するので、例えば開発者が発表した新機能の数で評価されているのに、運用チームは物事が中断しないことを基準に評価されている場合、これらの2つは直接衝突します。変化はOpsの心のリスクと等しいので、新しいものに対してサポートするのではなく、それをリリースをさせないように動機づけられるからです。経営陣は、同じ目標を達成するためには、全員を同じ基準で評価する必要があります。

階層やKPIのようなものは、常にあなたが制御できるとは限りません。もちろん開発者でもボトムアップで、共通の文化の価値を表現することができます。ある時点では、組織と管理者はその光を見る必要があります。 良いことは、すべての企業がある程度の能力を備えたハイテク企業になるにつれて、以前より高い品質なアプリケーションリリースを頻繁にサポートすることを支援する必要性は収益に影響します。 経営陣は数字以外を聞くことはありません。

文化をOKにする

文化はとても主観的なので、効率の環境を維持する原則とは対照的に、DevOpsの戦術にフォーカスするほうが簡単です。 文化エンジンを地面から降ろすのは難しいですが、良いニュースは、いったんそれが始まると非常に自立しているということです。 文化の鐘を鳴らすことは難しいです。これは、あなたがそれを作成することを熟考したとしても当てはまります。

上記のフレームワークとともに、ボールを投げて、結果が出るまで耐える自信を持つことが、成功への鍵です。 DevOps文化を受け入れる組織は、ソフトウェア配信をよりシームレスにして、最先端の開発の実践をより成功させるでしょう。

2017年12月8日  (更新日:2022年3月9日)    |    インシデント&アラート

サイロを壊す:ベンダー間のデータを関連付ける

DevOpsのへの移行で、一連のサイロからなる ソフトウェアデリバリーチェーンがなぜ悪いのか理解されるようになりました。 サイロは異なるチーム間のコミュニケーションを複雑にし、デリバリー遅延や手戻り、バグにつながります。

インシデント管理においては、あるベンダー製品の管理データと別のベンダー製品の管理データを分けるというサイロがあります。このサイロは、複数ソースからの監視データの収集と分析を困難にするため、インシデント解決を妨げます。

インシデント管理業務を効率的に流していくために、サイロをどのように分析していますか?

サイロを特定する

インシデント管理での作業の最初のステップは、サイロが最初に存在する理由を理解することです。

理由は簡単です。現代のインフラストラクチャは、多様なハードウェアとソフトウェアで構成されています。ほとんどのコンポーネントには特別な監視が必要です。特定のリズムに従って情報を特定の形式で出力し、特定の方法でデータを収集する必要があります。したがって、インフラストラクチャの各部分に関連する監視情報は、インフラストラクチャの他の部分からのデータと容易に比較できないため、サイロの中に入ってしまいます。

基本的な例として、Windowsを実行する10個のベアメタルサーバと、Linuxを実行する10個のベアメタルサーバで構成されるデータセンターを考えてみましょう。このシナリオでは、Windows用とLinux用の異なる監視ツールを必要とします。ホストが落ちていないかどうかなど、各タイプのオペレーティングシステムに関する監視情報の一部は同じですが、他のデータには違いもあります。そのため、各OS専用のツールでデータを収集する必要があります。したがって、Windows、Linuxそれぞれが専用ツールでデータを監視するエコシステムを備えた明確なサイロになります。

これは単なる例です。モニタリングする2種類のベアメタルサーバだけでなく、各種のハイパーバイザ上で実行される仮想サーバ、各種デスクトップOSを実行するワークステーション、いろいろなモバイル機器やモバイルOS、バージョンなど実際の現場ではさらに複雑になります。

サイロを壊す

シームレスで全体的な監視の可視性を得るために、インフラストラクチャ内の各監視コンテキストを分離するサイロをどのように排除するか。このソリューションには2つの部分があります。

ステップ1:データ収集の集中化

最初のステップは、さまざまなタイプの環境から情報を収集し、その情報を中央の場所に転送できるインシデント管理ソリューションを実装することです。 こうすればエンジニアはインフラストラクチャ全体を1点で監視することができます。 インフラストラクチャのさまざまな部分を監視するために個々のサイロを調べる必要はありません。

集中型のデータ収集には、複数のソースからの監視情報を集約するのに十分な機能を持つインシデント管理ソリューションが必要です。 これは簡単な作業ではありません。 幅広い環境とエンドポイントをサポートするためには、さまざまなタイプの監視システムと統合する必要があります。

ステップ2:データを翻訳する

2番目のステップは見落としやすい点です。インシデント管理チームは、多くの監視ツールのデータを集約し一元管理することに加えて、すべてのデータを一貫したフォーマットに変換する必要があります。

すべてのエンジニアがあらゆるソースからのアラートを解釈して対応できることを保証する唯一の方法は、データ変換だけです。データが共通のフォーマットに翻訳されない場合、エンジニアは特定のタイプの監視システムに必要な特別の知識を持たなければならないか、または特定ベンダーのスキーマを知ってそのシステムから発生したデータを理解する必要があります。このように、中央の場所ですべてのデータを利用できるようにするだけでは、複数のシステムを隔てる大きな障壁が依然として存在するため、サイロを分解することはできないでしょう。

たとえば、ZabbixとNagiosで「エイリアス」という用語の使われ方を見てみましょう。以前の監視システムでは、エイリアスは基本的に各種コンフィギュレーションの略語として機能します。対照的に、Nagiosでは、エイリアスはホストの名前です。この違いを理解しないまま、ZabbixシステムとNagiosシステムの両方のデータが集中ダッシュボードに集約されていたら混乱するでしょう。

効果的なインシデント管理のためには、ベンダーやプラットフォーム固有の用語を単一の言葉に置き換えるソリューションが必要です。 PagerDuty Common Event Formatで有効になっているようなイベントの正規化だけで、レスポンダは複数のソースからのデータを簡単かつ正確に解釈できます。

現代のインフラの複雑さは、サイロを避けることを困難にしています。しかしそれは、監視情報がサイロの中になければならないということを意味するものではありません。さまざまなソースからの監視情報を集約し、オンコールチームの誰でも理解できる言語に変換することで、インシデント管理チームはインフラストラクチャ内に存在するサイロを分解することができます。彼らは、シームレスなコミュニケーションと、機敏なインシデント対応が可能になります。

2018年6月20日  (更新日:2022年3月9日)    |    インテグレーション&ガイド

BMC TrueSight Pulseインテグレーションガイドを追加しました

BMC TrueSight Pulseは、DevOpsチームにリアルタイムのサーバーとアプリケーションの監視機能を提供してクラウド、VM、または物理サーバーを監視できるようにし、さらに問題を早期に見つけて修正するための、1秒ごとのメトリックを提供します。TrueSight Pulse側にはPagerDutyと連携するためのメニューが用意されており、簡単に統合することができます。

詳しくはこちら

2018年3月25日  (更新日:2022年3月9日)    |    インテグレーション&ガイド

BigPandaインテグレーションガイドを追加しました

BigPandaのデータサイエンスプラットフォームは、自動的にすべてのITアラートを相関させるため、ITの問題を迅速に検出、理解、解決、防止することができます。 BigPandaからPagerDutyインシデントを作成するには、BigPandaのインシデントをPagerDutyと共有するときに通知を送信するようにインテグレーションを設定します。

詳しくはこちら

2018年11月28日  (更新日:2022年3月9日)    |    インテグレーション&ガイド

PagerDuty、AWS CloudWatch、GuardDutyなどとのインテグレーション4種を発表

”PagerDuty Launches New AWS Integrations for CloudWatch, GuardDuty, CloudTrail, and Personal Health Dashboard”

by Andrew Marshall

Amazonの元従業員によって設立された会社だから当然と思われるかもしれませんが、PagerDutyはAWSユーザーが何らかのシグナルから自動的に正しい洞察と行動を導くのを何年も助けてきました。 当社のAmazon CloudWatchとのインテグレーションを使えば、各チームは顧客に影響を与える問題を積極的に軽減し、自信を持って組織がAWSとハイブリッド環境の両方を更新し、拡張していくことができます。

今年初め、 AWS Marketplace のEnterprise Contracts for AWS Marketplace を通じて、PagerDutyのサブスクリプションがAWSのお客様にご利用いただけるようになりました。 今週のAWS re:InventでPagerDutyは、AWS CloudWatch Events、GuardDuty、CloudTrail、Personal Health Dashboardのための全く新しいAWSインテグレーションをローンチしたことをラスベガスで発表しました。

Amazon CloudWatch(Events, Alarms):AWSサービスへのゲートウェイ

AWSユーザーは全AWSエコシステムの一部として展開したAWSサービスのステータスを監視するために使うパフォーマンスデータを、Amazon CloudWatchを利用して得られます。パブリッククラウドリソースを活用しても、ユーザーがサーバーの基盤となるサーバーの状態やパフォーマンスを無視することはできません。 実際には、使用するさまざまなツールを監視することは、企業が重要なアプリケーションをAWSに移行するにつれて、ますます重要になっています。

CloudWatch AlarmsとのPagerDutyのインテグレーション(AWSと当社に共通するユーザーがしばらく使用していたもの)は、ユーザーがリソースの使用状況(メモリの最適化など)をカスタマイズした細かなアラームしきい値を設定することで監視できました。 これらのアラームがトリガーされると、PagerDutyを介して必要な解決の自動処理を始められます。 これは非常に強力な組み合わせです。PagerDutyが提供する中で一番の人気のあるインテグレーションではないにしても、それが人気のあるインテグレーションの1つである理由は驚くことではありません。

非常に便利なツールですが、CloudWatch Alarmsは指定期間に1つのメトリックしか監視せず、全期間で同じしきい値を基準にして、あるメトリックの値がそれを超えた場合に1つまたは複数の指定されたアクションを実行します。 言い換えれば、特定の時点で一度だけアラームが発生します。 今週のAWSでは、当社のAmazon CloudWatch Alarmsインテグレーションを補完する新しいAWSインテグレーションであるCloudWatch Eventsの提供を開始しました。

CloudWatch Eventsは、AW Sリソースの変更を記述するシステムイベントのストリームであり、CloudWatchが収集するメトリックを強化するものです。 「イベント」は、AWS環境を支えるサービスと同様に、AWS環境に起きる変化のことだと考えてください。

現代のITOpsチームとDevOpsチームにとって、変化を監視することは、エコシステムの継続性とパフォーマンスの維持のために不可欠です。 たとえば、各チームはEC2インスタンスが状態を「pending」(保留中)から「running」(実行中)に変えたかどうかを知る必要があります。また、「スケール」が実際に「オートスケール」でどのくらいの頻度で行われているかを知る必要があります。さらに、AWS CloudWatchとCloudTrailとを併用すると、API呼び出しのようなことも確認できます。

弾力性と迅速なスケーラビリティは、AWS、Google Cloud、Microsoft Azureなどのパブリッククラウドプロバイダーにとって重要な価値を提案するものです。 「pay for what you use」(あなたが使っている分の対価を払う)サービスとして、AWSの請求書を見ることは、ほとんどのチームにとっても非常に重要です。 CloudWatchインテグレーションにより、PagerDutyはAWSからの請求が一定のしきい値を超えた場合にあなたに警告するので、無計画なスケーリングを避けることができます。

CloudWatch Alarmsの上にCloudWatch Eventsインテグレーションの機能を追加することで、PagerDutyは、よりしっかりしたAWSのデータの集合に基づいてチームのデジタルオペレーションを自動化することができます。PagerDutyのお客様は、以下のような多くのAWSサービスのデータを活用することもできるようになります。

Amazon EC2インスタンス AWS Lambdaファンクション Amazon Kinesis Data Streamsのストリーム Amazon Kinesis Data Firehoseの配信ストリーム Amazon ECSのタスク Systems Manager Run Command Systems Manager Automation AWS Batch ジョブ Step Functionsステートマシン AWS CodePipelineのパイプライン AWS CodeBuildプロジェクト Amazon Inspector Assessment Templates Amazon SNSのトピック Amazon SQSのキュー

オンデマンドサーバー、AWS、Azure、Google Cloud、またはハイブリッドインフラストラクチャなどあらゆる組み合わせを使用している場合でも、PagerDutyはインフラストラクチャから重要な信号を収集し、リアルタイムオペレーションを強化します。

Amazon GuardDuty

最近では、AWSの shared responsibility モデルとうまく一致する「security is everyone’s responsibility」(セキュリティは誰でも責任がある)という言葉を普通によく耳にします。セキュリティはみんなの仕事でもあり、 PagerDutyのAmazon GuardDutyとのインテグレーションにより、レスポンスワークフローを自動化するだけでなく、セキュリティ専門家にエスカレートするという面倒を軽減することで、セキュリティの管理権限を開発者にもたすことができます。 Amazon GuardDutyを使用すると、組織のAWSエコシステムやその上に構築されたアプリケーションに悪影響を及ぼす可能性のある、悪意のある行為や不正行為を継続的に監視できます。 たとえば、予期しないAPI呼び出しや侵害されたインスタンスを心配する必要はないでしょうが、その情報を収集してより深い分析が行えるようにする方がよいでしょう。

そこが、PagerDutyとDevSecOpsが入るポイントです。CloudWatchでマシン指向の出力を収集することは、最初のステップに過ぎません。脅威の性質、全体的な影響、および正しい対処方法を判断するためのワークフローが必要です。 Amazon GuardDutyによって脅威が検出されると、PagerDutyはレスポンス・ルールに基づき、その重要なセキュリティ問題に適切な人物に、自動的に通知します。 さらに、 PagerDuty Event Intelligenceを使用して脅威を他の問題とグループ化し、同様のアラートに埋もれさせるのではなく、問題に対処する正しいコンテキストを提供することで、チームは騒音を削減できます。 これらのすべては、さまざまな記録システム(Jira、ServiceNow、Remedy、Cherwellなど)とのシームレスなインテグレーションによって実行できます。

Amazon Personal Health Dashboard

AWSにはたくさんサービスがあります。 そして、彼らはおそらく、今週さらにいくつか新サービスを立ち上げる予定です。 これらの新しいサービスは、AWSユーザーに新しいソフトウェアを構築しサポートするための優れた柔軟性とパワーを提供しますが、AWSサービス、地域、およびゾーンの現在の状態を、組織がはるかに容易に知ることができます。例えばした下の図は北米向けのAmazon Personal Health Dashboardのスクロール表示です。

AWSは、このAWS Personal Health Dashboardの中の問題点を理解しています。Service Health Dashboardは全体としてはAWSサービスの一般的な状態を示してくれますが、Personal Health Dashboardは、あなたのチームが毎日気にしているAWSサービス群に関するこれらのアラートは役に立ちますが、その知識であなたは何かをする必要があります。

新しいPagerDuty AWS Personal Health Dashboardインテグレーションによって、このデータを取り込んで、どうやって、いつ、そしてだれと一緒に対応するかといった、あなたが問題解決のために取る必要があるステップを自動化できます。各チームは、問題の原因となっているAWSサービスでのサポートプレイとチケットを追加し、組織内の全員にAWSサービスの中断に迅速に対処するために必要な情報を提供できます。

もしre:Inventに出席し、Personal Health DashboardとPagerDutyのインテグレーションについてもっと知りたい場合は、AWSが提供する以下のセッションをチェックしてください。

日時: 11月26日(月曜日)午後4時

場所: Bellagio、レベル1、グランドボールルーム6

セッション:Optimize Performance and Reduce Risk Using AWS Support Tools (ENT316-R1)

日時: 11月27日(火)午前11時30分:

場所:Mirage、Mirage Event Center C3

Amazon CloudTrail

AWSとエンドユーザの間のもう1つの共通の責務は、コンプライアンス、ガバナンス、および運用監査です。 サーバーがデータセンターにないからといって、それらのワークストリームを放置することはできません。 AWS CloudTrailは、AWSエコシステムのガバナンス、コンプライアンス、運用監査、リスク監査を可能にします。

チームがAWSエコシステムで発生するさまざまなイベントのログを保存できるようにすることで、Amazonは、AWS Management Console、AWS SDK、コマンドラインツール、およびその他のAWSサービスを通じて行われるアクションを含む、コンプライアンスを管理するための強力なツールを提供します。 あなたが容易に想像できるように、こういったことは、戦いの半分です。

PagerDutyの新しいAWS CloudTrailインテグレーションにより、チームはDevSecOpsのプレイに使用するAWSのイベント履歴全体を収集し、必要に応じてアクションを自動化し、JiraやSNOWのような記録システムとシームレスに統合することができます。 PagerDutyは、DevOpsとDevSecOpsのチームに対して、オペレーション上のノイズをカットして必要なコンテキストだけを与えることで、他の進行中の問題との相関関係やグループ分けを可能にします。 チームは、例えば、Amazon S3で隠れたデータの逆流が発生していないかどうかを特定したり、Amazon Virtual Private Cloudでセキュリティグループルールが変更されたときに瞬時に警告を発することができます。どちらの例でもPagerDutyを使用して、正しいレスポンスを即座に自動化できます。

re:Inventでお会いしましょう DevOpsのコンピテンシーを持つAWSパートナーネットワークの先進的パートナーとして、PagerDutyは re:InventでAWSと共同でこれらのエキサイティングな新しいインテグレーションを共通の顧客に共有できることを喜ばしく思います。 今週ラスベガスにいる場合は、ブース1023にご来訪ください。PagerDutyは無料の14日間のトライアルを提供していますが、それはAWS Marketplaceを通じて調達することができます。 また、 AWSのこれらの統合の詳細についてはこちらをご覧ください 。

次のAWSインテグレーションを使ってください:

https://support.pagerduty.com/docs/aws-cloudwatch-integration-guide

https://support.pagerduty.com/docs/aws-guardduty-integration-guide

https://support.pagerduty.com/docs/aws-cloudtrail-integration-guide

https://support.pagerduty.com/docs/aws-personal-health-dashboard

GET STARTED

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2018年11月21日  (更新日:2022年3月9日)    |    ニュース&告知

AWS re:Invent 2018へのカウントダウン

もう1年になるのかと思うと信じられませんが、もうすぐAWS re:Inventがやってきます。いつものように、PagerDutyはグローバルなAWSコミュニティに参加して、デジタルオペレーション、ネットワークセキュリティ、アプリケーションパフォーマンスを改善するためのアイデアを共有できることにワクワクしています。

AWS re:Inventは、あなたがたが私たちのチームと出会い、交流し、社交を深め、PagerDutyがどのように組織のリアルタイムデジタルオペレーションの変革を支援するのかを学べる絶好の機会です。今年のハイライトは、PagerDutyがAWSとハイブリッドクラウド環境全体でどのようにデジタルオペレーションを可能にするのかです。PagerDutyがDevOpsとITOpsチームに、顧客と収益に影響を与えるインシデントを積極的に減らし、組織が革新性、生産性、成長を発揮できるようにする方法を紹介します。

さらにあなたは、実用的な情報をリアルタイムで提供する2つの新製品をチェックして、ビジネスチームとテクニカルチームが最高の顧客体験を提供することもできます。PagerDuty Visibilityは、ITとビジネスのギャップを埋め、AWSのインシデントが顧客にリアルタイムで与える影響を示し、チームが積極的に対応できるようにします。PagerDuty Analyticsは、専門知識と一緒に、機械と人間のレスポンスデータを組み合わせ、より良いビジネス上の成果につながるオペレーション方法に関する洞察を提供します。

PagerDutyはどこに? 1週間を通じて出展する場所は

ブース#1023です。ここでPagerDutyチームに会い、クールなお土産を手に入れ、毎日行われる500ドルのAirbnbギフトカードの抽選にエントリーできます。

11月26日 (月)

スピーカーセッション:リアルタイムオペレーションでチームの生産性を引き出す(Unleash Team Productivity With Real-Time Operations)に登場します

時刻:午後1時〜午後2時

場所:Venetianホテルの4階、Delfino 4005

PagerDutyの新しい事例であるDave CliffeとIntuitのDevSecOpsリーダーShannon Lietzが、以前に存在しなかったスケールでリアルタイムオペレーションを処理し、優先順位を付ける必要がある理由について議論する予定です。

セッションでは、 最新のインシデント管理のベストプラクティスと組み合わされた機械学習、自動化、分析の革新が、運用パフォーマンスとチームの生産性を向上させ、より良いビジネス成果をもたらす方法を探ります。

11月27日(火)

イベント:パブクロール – セキュリティゾーン

時刻:午後6時〜午後8時

場所:VenetianホテルのAquaKnox

一緒に飲みましょう! 当社はパブクロールの「セキュリティゾーン」をDatadogとMongoDBと一緒に開催しています。Pag​​erDutyチーム、イベントスポンサー、業界のAWSエキスパートとのカクテルやネットワーキングのためにAquaKnoxにおいでください。

現地でミーティングをしたい方に

PagerDutyがあなたの組織にできることを知るために会議を予約したり、技術的な質問をしたり、製品のデモを見ることができます。PagerDutyがリアルタイムのデジタルオペレーションを通じてより良いビジネスパフォーマンスを後押しする方法を学べます。

Twitterの@pagerdutyをフォローして、我々のニュースとAWS re:Inventからの更新情報を追ってください。ラスベガスでお会いましょう!

(注:残念ながらDigital StacksはAWS re:Inventには出展しません。)

GET STARTED

本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2018年2月14日  (更新日:2022年3月9日)    |    インテグレーション&ガイド

AWS CloudWatch統合ガイドを追加しました

Amazon Web Services CloudWatch は、AWSリソースとユーザーアプリケーションの監視を提供します。 AWSは、データを収集し、洞察を得て、ユーザーにアプリケーションの問題を解決するよう警告します。 AWS CloudWatchを使用すると、システム全体でリソースの使用状況を把握でき、任意のメトリックが指定した閾値を超えた場合の通知を設定できます。これらのアラームは、PagerDutyに自動的に送信され、PagerDutyは正しい連絡方法でオンコール担当者に確実に警告します。

詳しくはこちら

2017年12月14日  (更新日:2022年3月9日)    |    インシデント&アラート

インシデント対応のボトルネックを回避する

インシデント 対応のボトルネック―今お使いのインシデント 対応システムでは少ないかも知れませんが、確かに存在することをご存知でしょう。オンコールのチームやお客様のためにボトルネックは最小限に抑える必要があります。最も重大なボトルネックのいくつか、およびそれらを回避する方法を見てみましょう。

あなたの目標は何ですか?

まず、プロセスのボトルネックを理解する前に、そのプロセスの目標が何かを理解する必要があります。インシデント対応の目標は何でしょうか。

ほとんどのインシデント対応チームにとって目標はおそらく次のようになります。

インシデントの発生を防ぐ**。 インシデントの予防は、問題解決を主な目的とするインシデント管理の手には余る可能性がありますが、予防は計画外の作業を削減するために重要です。 損害を最小限の範囲にとどめる**。実際には、インシデント管理における予防的取り組みの大部分はこの点に焦点に当てられています。インシデントが発生しないようにすることができない場合でも、インシデントが広がらないようにすることができます。 インシデントを迅速に解決する**。全てのインシデントを解決できるわけではなく、全ての修正が根本的な問題を解決するわけではありませんが、迅速なインシデント解決は一番重要です。

各ボトルネックを監視する

上記がインシデント対応の基本的な目標である場合、ボトルネックはそれらの目標を達成することを困難にします。これらの中で最も重要なものは次のとおりです。

優先順位を適切に設定できない

優先順位付けは、インシデント解決とインシデントの影響の封じ込めに利用できる最も重要な手段です。深刻な影響の可能性に基づいて、最も注意が必要なインシデントに焦点を当てることができます。インパクトが比較的少ないインシデントは脇に置いておくこともできますが、それでも多大なチームの時間と注意が取られます。適切な優先順位を設定しなかった場合、重要なインシデントの一部が速やかに処理されない、あるいはまったく処理されないことがあります。

過負荷とアラート疲れ

対応チームがアラートの量に圧倒された場合、どの問題を優先すべきか判断する時間がないため、または真のインシデントをノイズのアラートから見分けることができず、麻痺して全てに対応することができなくなります。これは慢性的なアラート疲れにつながる可能性があります。チームメンバーが無意識にほとんどのアラートを無視する精神状態に陥るため、僅かなインシデントにしか集中できなくなります。

アラートのノイズをフィルタリングするための(典型的には自動化された)システムが絶対必要です。対応不可能なアラートを抑制し、関連するアラートを1つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。

不十分な準備、訓練、経験

理想的には、全てのインシデント対応チームは、問題を迅速に診断でき、各インシデントを修正するためにどのツールとテクニックを使用すべきかを理解している、高度に熟練した技術者で構成する必要があります。

このような問題を最小限に抑える最良の方法は、インシデント対応者のための正式なトレーニングシステムを用意すること、新しいチームメンバーは可能な限り経験豊富なチームに配属すること、チームに適切なドキュメントを用意することです。一貫性と再現性の高いベストプラクティスを実現するためのドキュメントには、基本的な手順のマニュアルや、索引付きで簡単に検索できる相互参照の効くデータベース(過去のインシデントなど)が含まれている必要があります。

メジャーな新製品のロールアウトに対する不十分な準備

メジャーなアプリケーションのリリースの際―それは全く新しいアプリケーションやサービスかもしれませんがー開発者がいくつかの重大なバグを見逃して大量のアラートが押し寄せる事態に対応チームは備えておくべきでしょうか。結局のところマーフィーの法則はいつでも有効です。それが起こるのは広く使われているプログラムのアップデートや、1つ2つのバグが絡みあったトレースしにくいエラーを発生させる場合です。対応チームが準備できていない場合、時間とリソースの全てが優先順位の高いアラートの暴風に巻き込まれ、関連性のないその他のインシデントを処理するための余裕はほとんどありません。

もちろん、リリース前にA/Bテストやカナリアテストなどでアップデートが適切にテストされていることが理想的です。応答チームが配備作業に加わっていれば、問題がはるかに小さなうちに対処できる機会があります。しかし、限定的な導入から始めるという決定をインシデント対応チームが下すのは不可能であり、十分にテストされていないリリースに対処しなければならない可能性があります。

このような状況では、全ての対応者をオンコール待機にするか、アップデートで起こる全ての問題を処理する特別なチームを指定する必要があります。どのアプローチが最も効果的かは、少なくとも更新の範囲と利用可能な対応チームのリソースによって決まります。しかし、計画はいつでも何度でも必要に応じて変更できますし、計画を立てておけば準備ができていない場合とは大違いになります。

ボトルネックの解消

他にも、時代遅れの障害が発生しやすいインフラや過負荷のインフラから生じるインシデントや、インシデントとは無関係のタスクで対応チームの時間が取られるなど、多くのボトルネックがあります。しかし、私たちが列挙したボトルネックは、インシデント対応チームが時間を消費した理由の多くを占めており、ここで提案した修復アプローチは、それらの大半をなくすのに役立ちます。