Blog
ブログ

2018年1月13日  (更新日:2022年3月11日)

Zabbix 3.xのインストレーションガイドを追加しました

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

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

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年1月2日  (更新日:2022年5月19日)

IoTのインシデント管理を助けるPagerDuty API 2.0

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プラットフォームを準備するものであり、エンドユーザーと開発者のエクスペリエンスをより快適で、拡張性があり、信頼できるものにする無限の可能性をもたらします。

続きを読む
インシデント&アラート
2018年1月1日  (更新日:2022年3月9日)

オンコールエンジニアのための準備

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

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

最初の対応が重要

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

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

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

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

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

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

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

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

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

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

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

正しい人に通知する

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

トラブルシューティング

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

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

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

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

続きを読む
ベストプラクティス
2017年12月31日  (更新日:2022年7月14日)

運用コマンドコンソールの中でビデオ会議をするには

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

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

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

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

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

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

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

以上でおしまいです!

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

あなたのチームがPagerDutyプラットフォームを拡張した妙だけど素晴らしい方法はいくつあります? support@pagerdurty.comで電子メールを送って知らせてください!

続きを読む
インシデント&アラート
2017年12月30日  (更新日:2022年5月13日)

システムダウンを回避するための7つの方法

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

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

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

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

3年間で3倍になったPagerDuty:エンジニアリング組織のスケーリング

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

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

アラート管理プロセスの最適化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アラートを微妙に調整

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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月29日  (更新日:2022年3月10日)    |    インシデント&アラート

ブランドと評判を守るインシデント対応

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

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

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

出血を遅らせる

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

ブランドの再構築

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

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

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

買うべきか作るべきか?

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

なぜビルドするの?

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

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

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

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

コスト

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

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

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

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

インテグレー?

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

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

ビルドする時期

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

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

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

あなたの輝く時間が来る

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

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

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

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

Twitterはコールセンターをなくす

インシデント管理における外部メディアの重要性

インシデント管理について偏狭な考え方に陥るのは簡単です。私たちは何カ月も問題を警告するシステムの設計と構築を行い、我々がキャッチできなかった問題を発見するために顧客サポートのチャネルも構築しました。この考え方は間違っていませんが、このアプローチではなく、TwitterやFacebookなどのSNSで問題を報告するユーザーが増えています。

新たな道を歩むソーシャルメディア

ソーシャルメディアは、企業がカジュアルな雰囲気でユーザーと直接つながる素晴らしい手段として、より密接な双方向コミュニケーションの扉を開いています。ソーシャルメディアは個人が企業とコミュニケーションをとるだけでなく、より効果的な方法でユーザーサポートを得ることもできます。

一般的に、ユーザーが電話やサポートチケットなどの伝統的なルートでサポートを得ることができない場合、ツイートで不満を述べるとすぐに答えがが得られることがあります。SNSは苦情を訴える手段だけではありません。多くのユーザーは、ソーシャルメディアを企業とのコミュニケーションに使用するのが好きです。

私も何度かツイートしたことがあります。

彼らのサイトは500のエラーを発生させている?

素敵なJavaScriptはある?

開発者として私が気づいていないかもしれない問題を指摘していただければ幸いです。「何かを見つけたら話す」です。

同期 vs. 非同期

ソーシャルメディアによるサポートの「報告」の側面は強力ですが、他にもより大きな利点があります。ソーシャルメディア(特にTwitter)は、「リアルタイム」を感じさせるからです。

たとえば、電子メールは非同期通信メディアであり、顧客サポートの手順では受けた質問はキューに追加されます。そこに緊急感はありません。一方、Twitterにはより同期的なフローがあります。電話やライブチャットのようなリアルタイムのサポートチャネルではありませんが、回答する時間が公に記録されているため、電子メールよりも緊急性があります。フィードバックは直接的かつ個別的なもので、あなたの問題を他と同様に重要なものと感じさせます。

干し草の山から針を探し出す

それでは、インシデント管理以外の質問に埋もれることなく、うまくやるにはどうすればいいのでしょうか。この問題の解決策はサポートチャネルと同じで、判定と引き継ぎです。

判定

ソーシャルメディアは顧客サービスのためだけに使用されるわけではないため、ユーザーサポート以外の書き込みで混雑することもあります。バグレポートをそれ以外から物理的に隔離することが重要です。単純にバグを非バグから隔離するだけでなく、レポート間の共通点を特定することも重要です。これによりパターンを検出し、問題が手に負えなくなりそうならばその前にエスカレーションすることもできます。たとえばコマンドコンソールは、ツイートなどのデータソースをインフラストラクチャ内の特定のイベントに関連付けたり、影響の範囲を視覚化したりすることができます。こうして、ソーシャルメディアへの反応からデプロイの失敗や停止が顧客に影響をもたらしたかどうかや、影響の程度を理解することができます。

引き継ぎ

問題が特定され、グループの他の部分から隔離されたら、適切な人やチームを割り当てる必要があります。これは、既存のヘルプデスクアプリケーションにレポートを転送するだけでなく、専用のソーシャルメディアサポートアプリケーションを使用して、多種多様な方法で実行できます。

ソーシャルメディアプラットフォームは、マーケティング部門だけが利用するものではなく、インフラストラクチャ内の問題に関するリアルタイムの情報を得る優れた方法であり、今日のデジタル世界では完全な可視性を提供するために不可欠なデータソースです。これらのプラットフォームに従来のサポートチャネルと同じレベルのプロセスと労力をかけることで、問題がより深刻なものになった後ではなく、最初のレポートが到着してすぐのインシデント対応が可能になります。

コールセンターが不要というわけではありませんが、顧客満足度をを確保するためには、ソーシャルメディアを介して入手可能な豊富な顧客データを積極的に活用しなくてはなりません。監視とインシデント管理戦略の重要な要素として、ソーシャルメディアはユーザーエクスペリエンスの質をより深く把握し、顧客のロイヤリティを向上させるための重要な要素です。

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

オンコールのシャドー中に驚いた5つのこと

シャドーイング( 訓練のためインシデント対応を見学すること )中のコールエンジニアは、医師の肩越しに開腹手術を見ているような感じがします。精密さとスピードが最優先事項であり、間違いは深刻な結果につながります。私はPagerDutyエンジニアリングチームのオンコールローテーションにシャドーオブザーバーとして1週間参加しました。

オンコール中、私は同じエスカレーションポリシーで、他のすべての人たちと同じように通知を受けました。エンジニアが緊急でセンシティブな状況に立ち向かうため、Slackで起こされると私も起こされます。私はストレスが人々を悪い状況に追い込むと予想しました。ところが、驚いたことにそれは完全に間違っていました。

コールは睡眠、食事、シンプルな文章は、何時間ものストレスを乗り切れるようにします。

思考、そしてほかの多くのものを中断するために鳴り響き、チャットチャンネルは一晩中炎上と対応を知らせるメッセージを流し続けました。オンコールの責任とストレスに押しつぶされそうなのに、エンジニアが見せる優しさ、助け合い、ユーモアに私は驚かされました。

励まし

シンプルな文章は、何時間ものストレスを乗り切れるようにします。

初日のシャドーイングの午後遅くに、私は最初の通知を受けました。私はSlackのチャンネルを見て、問題の調査が完了したのを知りました。チームは直ちに新しいマシンを停止し、再配置をしました。トリアージと診断の混乱の中で、そのオンコール担当者が私と同じく新人だと知りました。私たちはどちらもまだ1カ月足らずの新米でした。彼はこれまで一度も遭遇したことのない問題を修正していました。

夕方までに事態は回復しました。長い1日を終え、人々は家に帰って行きました。それでも、ベテランのエンジニアPがチームメイトKの応援に入っていました。

6:14 PM (P)すべて終わった?

6:15 PM (K)まだ、ホストを再起動してるところです。すべてがスムーズに進んでます

6:18 PM (P) その調子だ! 俺達はこいつのために半日つぶしたんだ

このような仲間の励ましは、プロジェクトに新しく加わった人、新人社員、新人エンジニアに自信をもたせます。シニアエンジニアからの励ましは経験の少ないエンジニアに質問する勇気を与えます。質問は新人がエキスパートになるための第一歩です。「その調子だ!」の一言は人々に力を与えます。

謙虚さと感謝

この初心者オンコールエンジニアは、その励ましにすぐ反応しました。彼は自分を助けてくれたシニアエンジニアに短い言葉で謙虚さと感謝を示しました。

6:21 PM (P)本当にあなたとMがいなければダメになるところでした。勉強になりました

Kが彼を助けた別のチームメイトの名前を挙げたのが嬉しかったです。DevOpsのエンジニアリングチームは、チームメイトを高く評価しています。彼らが今開発しているソフトウェアが明日、地獄のオンコール嵐を起こさないため、互いに頼り合っています。誰も常にすべてのことを知ることはできません。彼らは常に互いから学び、お互いに助け合わなければなりません。

上の例では、謙虚さと自己嫌悪の間の細い境界線が見えました。エンジニアは「学ぶことがとても大事」と述べています。この態度は「こんなことは絶対自分ではやりません」や「私にはこんなこと全部分かるわけないでしょう」とは異なります。謙虚で感謝の気持ちがあれば、チームメート同士の信頼を築けます。自己嫌悪は迷いと不安を引き起こすでしょう。

軽薄さとたくさんのGIFファイル

オンコール待機中は(幸せなことに)退屈でもあります。オンコールに入る予定が分かっていることはストレスを軽減してくれますが、それでも常に不安があります。幸運なことに、インターネット上のGIFファイルは、ストレスに満ちたオンコールシフトをユーモアで支えてくれます。

PagerDutyはユーモアの文化とカスタムGIFに特別な情熱を持っています。3つのタイムゾーンと2つの異なる国に分かれているこの楽しくてちょっとおバカなチームを観察するのが私は大好きです。オンコールでない人々がいつも明るいことに気づきました。

どうすればオンコールをよりポジティブにすることができるか

あなたがオンコールでない場合でも、チームと共にあれ 応援しよう。特に新人を 挑戦やリスク、時間のかかることを肯定する 感謝をもってあなたに直接影響を与えてくれた人々に接する。チームが将来どのような強みを持つか理解するのに役立つ ひょうきんに振る舞う。皆笑うのが大好き

たくさんの問題解決と心労を経験しましたし、他人が週末や夜にもオンコール待機をするところも見ました。そのまっただ中で、チームメイトが示す小さなジェスチャーが、あなたが1人ではないことを思い出させてくれます。

空が落ちてくると思うような時は、互いに品性ある振る舞いをすることが助けてくれるでしょう。

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

インシデントの経験を事後検証で最大活用

インシデントを経験した後 のポストモーティム(事後検証。post-mortem またはpostmortem と表記される)に 何をします? 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。

しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。

なぜポストモーティムするの?

しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。

ポストモーティムは基本的に以下の役割を果たします:

インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。

これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。

理解したあとに、責めないこと

大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス(すなわち、部門内での非公式で司会を立てた議論)を設定してください。

一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。

ポストモーティムはいつ必要?

すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。

ポストモーティムが必要な状況の例をいくつか示します。

データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント

ポストモーティムは学習を容易にする

ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。

これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。

ポストモーティムの基本要素

ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。

根本的な原因

ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。

例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。

対応

ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。

対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。

被害の影響範囲の確認と制御

ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。

ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。

恥と思わず、金と思え

ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。

PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。

2017年12月27日  (更新日:2022年3月10日)    |    DevOps

デジタルオペレーションの人間的側面

2017年2月28日の朝のこと、インターネットが広大な範囲で利用できなくなりました。 Slack 、Quora 、GitHub、Trelloなど、数千人が頼りにしている個々のサイトからサービスに至るまでたくさんのものが利用できなくなりました。たぶん、人為的ミスがインターネットの大部分をダウンさせたこの日を覚えているでしょう。AWSの幅広いコンポーネントが機能しなくなりました。一つの停止でインターネットが無秩序になったのは今回が初めてではありませんが、AWSの規模を考えれば、その影響はいつでもありうると感じられます。

多くの場合、危機の最中に重大な事件に対処する人間の側面を忘れることがあります。例えば人々に連絡する難しさや、個人的な連絡先情報を見つけること、複数のタイムゾーンに主要なスタッフが分散していること、会議から人を引き離すことなど、予期しない出来事のため計画していた作業を中断することなどです。

PagerDutyは、こういう時代に存在する最先端のデジタル運用管理プラットフォームです。私たちは、チームや組織が事態が悪化したときにPagerDutyを使いインシデントを先取りして管理することを支援し、チームがやりたい仕事に集中できるようにします。当社の製品は、予期せぬ事態が発生した場合の行動のプラットフォームとして機能します。私たちは主にエンジニアリングとITチームにフォーカスしてきましたが、チームや人をサポートする他のビジネス分野にとってPagerDutyがどんな意味を持っているかも考えていました。

過去には、エンタープライズシステムや人事部門こそが、AWS停止などの事態が発生したときに必要となる重要な人員の詳細を把握するシステムの責任者でした。人事チームはまた、大事な顧客への影響が発生したときに情報を提供する必要があります。私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合に、私たちが仕事をするために必要な重要な情報もそこにあります。私たちが日常的に利用している人気のあるサービス、社内のメッセージングとVoIPサービスは、すべて利用できなくなる可能性が隠れています。これらのクラウドサービスの大規模な停止またはダウンタイムの間、顧客と従業員に情報を提供し、行動と対応を調整することは困難です。

「 私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合、私たちが仕事をするために必要な重要な情報もそこにあります。」

現代の企業には、通常、人の情報をすべて記録したシステムがいくつもありますが、その詳細を最新の状態に保つインセンティブを人々に持たせていることはめったにありません。 PagerDutyのようなインシデントや危機対応の鍵を握るシステムでは、従業員全員が緊密な接触を維持する気にさせる深いインセンティブと日常のビジネスニーズがあります。そのプラットホームを活用して正確な人の情報を得、応答を調整すればスムースになります。

これは、ビジネス全体で高度に採用されているプラ​​ットフォームをHRチームが使用する絶好の機会であり、私たちを行動の心臓部につなぎとめ、妨げにならないように支援します。私たちが最も避けたいことは、素早い返事と行動を求められている最中に、社内で不要な騒音や官僚的な行動を作り出すことです。

従業員に対する環境的、物理的、またはデジタル的な脅威など、人事部門が責任を持つべき危機のことを考えてください。私たちに必要なのは、状況を管理し、重要な情報にアクセスし、サイロになったりワークフローにまぎれずに、あるいは、チケットによって遅くならずに応対できるようにすることです。いつもそうとは見えないかもしれませんが、HR部門は、さまざまな状況になると、しばしば第一級の対応ができる部門です。ベストプラクティスとアジャイルワークフローを使い重大な事態に対処するには、法律、設備、ベンダー、サイバーセキュリティチームと連絡する必要があります。

当社の顧客の多くは、物理的な在庫やサプライチェーンを持たないビジネスモデルを採用しています。デジタルインフラストラクチャがビジネスの主体であり、顧客の経験に大きな影響を与えます。エンジニアリングから法律およびマーケティングに至るまで、インフラストラクチャと顧客体験の成功に投資しています。リアルタイムの顧客への影響がある場合、そのインフラストラクチャ全体を調整できるプラットフォームを使う方が優れた対応ができます。

“ これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。”

テクノロジーに焦点を絞ったビジネスでは、エンジニアリングチームや開発チームが使用するプラットフォームやプロセスから学ぶ必要があります。これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。各チームが醸成した文化、つまり最前線に至るまでのカスタマーエクスペリエンスの説明責任を果たせること、チームが対策を組織できると信頼すること、非常に高い協調性から学んだこと、そしてDevOpsチーム、ITチーム、顧客が習熟してきたインシデント対応へのアプローチから、恩恵を受けることができます。ビジネス全体がこれから学ぶことができます。

“ HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。”

さまざまな機能が共有プラットフォーム上で共同して働ける新しい方法を見つけ出すことは私をワクワクさせます。例えばデータを集めることと機械学習を活用して、あるパターンが出現する前にそれを見つけたり、過去の反省から対策を覚えたり改善したりすることができます。 HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。私たちは社員が顧客のために構築した経験を彼らから借用していますし、オンコールエンジニアの人生をより良くしていくことで、デジタルビジネスに関わる全員の人生をより良くすることができるはずです。

2017年12月26日  (更新日:2022年3月9日)    |    DevOps

オムニチャネルで成功しているリテーラーのDevOpsを学ぶ

ウォルマートのようなリテーラー( 小売業者)の増加に伴い、eコマースとリテーラーの間の戦いが収束しつつあり、Amazonのようなeコマース企業の多くはオフラインでのプレゼンスを確立しています。この2方向の展開をサポートするため、リテーラーとeコマース企業は、優れたオムニチャネルカスタマーエクスペリエンスを提供することを目指しています。

リテールの世界のオムニチャネル

顧客は、店舗内、Webサイト内、モバイルアプリ内、またはソーシャルメディア内の全チャンネルでシームレスな体験ができると期待しています。世界最先端のリテールブランドはトレンドに乗っており、たくさん成功事例があります。以下は、オムニチャネルのリテール体験を提供しているブランドの好例です:

ディズニー:ディズニーランドでの休暇を計画するのは大変です。しかし、ディズニーのWebサイトやモバイルアプリのおかげで、レストランや観光スポットなど、休暇全体をオンラインで計画することができます。また、各アトラクションの待ち時間を知ることもできます。

スターバックス:スターバックスの特典カードを使えば、コーヒー代でキャッシュを使い切ることはありません。モバイルデバイスから簡単に特典カードを取り出して、いつでもカウンターで使えます。

ノードストローム:ノードストロームは、顧客がiPhoneアプリで行う注文を店内のスタッフが補助することで、優れたカスタマーエクスペリエンスを提供しています。各スタッフはアイテムの在庫を確認でき、特定のアイテムが在庫切れの場合、すぐにiPhoneで予約して顧客の家に届けることができます。顧客はオンラインで商品を購入して店頭で持ち帰ることもでき、返品も簡単です。

これらのチャネルでのエクスペリエンスをサポートするためには、深くよく統合されたバックエンドと、一貫したフロントエンドインタフェースが必要です。しかし、これは以前よりもずっと簡単になりました。従来のインフラストラクチャ、ツール利用、そして開発プロセスを放棄して、リテールアプリケーションを構築するための最新のDevOpsアプローチに移行すればよいのです。顧客は絶えず新しい機能や体験を求めており、そのために頻繁になる更新は、安定性を損なうことなくアジャイルさと正確さを最大化する方法で展開する必要があります。これは、デジタルチャネルと物理チャネルをシームレスに統合したエクスペリエンスを構築するために不可欠です。何千もの日常的なやりとりは破綻を生じやすく、また、人気ブランドはサイバー攻撃の目標とされやすいです。何百万人ものユーザーをサポートするためには堅牢なシステムが必要です。システムの可用性とセキュリティを確保する必要があります。これは簡単な仕事ではありません。

いかにしてDevOpsチームがオムニチャンネルリテーラーをサポートするか

インフラストラクチャ層から始めて、アプリケーションスタックまで移動し、オムニチャネルのリテールアプリケーションを構築する際に、DevOpsチームが留意べきことを理解しましょう。

クラウドに移行する

モバイルは、オムニチャンネルのリテールを考える際に最も重要なメディアです。これは、顧客にアプローチする最も個人的かつ強力なチャネルです。どこにいても、お客はあなたの会社とやりとりして、都合のいいときに買うことができます。しかし、ほとんどのリテールアプリは、過去に使われていたクライアントサーバモデルをベースにしていて、現代の最先端の消費者をサポートすることはできません。複数のデバイスやモバイルオペレーティングシステム用のアプリケーションを構築するには、クラウドテクノロジーを活用する必要があります。しかし、いくつかのクラウドツールをあなたのレガシーなスタックに投入するだけでは足りません。AWS EC2などのクラウドサーバでアプリケーションを実行したり、AWS S3などのブロックストレージにデータを格納したり、Sauce Labsなどのクラウドベースのテストプラットフォームを使ったり、Prometheusなどのクラウドネイティブな監視ツールを使ったりする場合は、全システムをクラウドで稼働させるか、少なくともそこへの移行を開始しなければなりません。

マイクロサービスモデルにゆっくりと移行する

マイクロサービスは、単一のモノリシックなアプリケーションを、小規模なクロスファンクショナルチームによって開発・管理される小さなサービスに分解するアプローチです。このタイプの複合型のシステムにより、新しい機能をより早くリリースできます。さらに、あるサービスに障害が発生しても、システム全体をダウンさせることはありません。しかし、マイクロサービスへの移行は、一度に1ステップで行う必要があります。最初のバッチが安定した後に、いくつかの機能を切り分けてください。マイクロサービスアプリは、従来のツールセットを使用する場合に限り、管理が難しくなります。幸いにも、DockerやKubernetesのようなコンテナ技術は、マイクロサービスの管理を容易にしています。

VMからコンテナへの切り替え

クラウドへ移行することが最初にやるべきことです。クラウド内にもう移行していても、アプリをコンテナで実行することが重要です。マイクロサービスモデルに移行すると、サーバインスタンスごとにハードウェアハイパーバイザとOSのオーバーヘッドがアプリのパフォーマンスを低下させます。マイクロサービスアプリケーションを拡張するには、コンテナにコードをパッケージ化する必要があります。コンテナ化すると全く新しいツールセットを使うことになります。たとえば、Kubernetesのようなオーケストレータを活用して、数千のコンテナを管理する必要があります。幸いなことに、コンテナ周辺のツール事情は昨今急速に成熟しました。今日、多くの世界クラスのアプリは、コンテナを使用して確実かつ安全に稼動しています。業界は、クラウドネイティブコンピューティングファウンデーション(CNCF)が認めた標準規格を整理統合しているところです。

分散データストア

インシデント管理でシステムを保護する

現代のマイクロサービスベースのコンテナ駆動型システムでは、多くのパーツがあり、これらのパーツはしばしばフェイルします。DevOpsの呪文の「早く進んで前向きに失敗する」とは、これらの失敗にすばやく反応し対処できる必要があることを意味します。パフォーマンスとセキュリティの両方が、オムチャンネルのリテールアプリの最大の課題です。サイバー犯罪者は多数のユーザーを持つアプリに引き寄せられますが、リテールアプリは名前、住所、クレジットカード情報などの価値のある重要なユーザーデータを数十億単位で持つことが知られています。システム障害やサイバー攻撃から守るには、データポイントを集中管理し、問題に応じて適切な対応者をリアルタイムで把握するインシデント管理システムが必要です。

大規模なDevOpsチームでは、重要な通知が失われる可能性があるため、適切なメッセージが適切な人に届くようにルーティングシステムが必要です。インフラストラクチャの複雑さが増し、大量のデータを処理する必要があるため、機械学習を活用してデータを理解し、重要なポイントに人々が集中できるようにするソリューションが必要です。オムニチャネルリテール向けのインシデント管理ツールは、システム全体にわたる監視、チケット発行およびその他のデータソースを相互に関連付け、集中化することができます。最先端のインシデント管理プラットフォームにより、疑わしいパターンを特定し、インシデントがエスカーレートする前に適切な人材を確保できます。

オムニチャネルのリテールは単純ではないので、完璧なシステムを構築するためには数年以上の時間が必要です。ただし、ここに記載されている方法とツールは、DevOpsチームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。

2017年12月26日  (更新日:2022年5月19日)    |    DevOps

現代のインフラストラクチャに真のフルスタック可視性を

「フルスタックの可視性」とは?

ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性がITインフラストラクチャの構成方法に依存するだけでなく、あなたが何が見たいかにもよるためです。極論すればフルスタックの可視性は、ツール、アプリケーション、システム、サービス、および全体的なインフラストラクチャの状態を一覧できるようにすることです。

近代的なインフラ

まず、現代のアプリケーションとサービスをホストするフルスタックインフラストラクチャのタイプを特定してみましょう。以下は、現代のインフラストラクチャに見られる最も一般的なコンポーネント要素です。これらは、仮想デバイスと物理デバイスのミックスとしてオンプレミス、クラウド、またはハイブリッド環境でホストされる場合があります。

現代のインフラストラクチャコンポーネント

アプリケーションとツール オペレーティングシステム ミドルウェア ネットワーク データベース ストレージ Webサーバ 演算装置

これらのインフラストラクチャコンポーネントはすべて、膨大な量の構造化データと非構造化データの両方を生成します。この指数関数的に急増するデータの量と多様性はITOps、DevOps、開発チームに挑戦を突き付けます。つまりシステム、アプリケーション、サービスの可用性を高く維持し、最適なパフォーマンスを発揮させるためにカギとなる情報を収拾し解釈し、実用的な洞察を抽出することを要求します。

以下は、今日の組織がインフラストラクチャとアプリケーションのパフォーマンスを自動化するために採用しているツールの例です。これらのツールのそれぞれは、インフラストラクチャ、アプリケーション、サービス、コードの展開、ビルドなどのステータス、健全性、脆弱性を知らせるデータを生成することができます。

インフラストラクチャ、アプリケーション、自動化ツール

オートメーション/継続的インテグレーション ソースコード管理

構成管理とプロビジョニング リポジトリ管理

ソースコードとリポジトリ管理 プロビジョニング

デプロイ リリース管理

データベース テスト

モニタリング セキュリティ

ビルド クラウドIaaS

マイクロサービスと仮想化

どんな風に可視化できるか

アプリケーションとサービス、システムは、データテーブル、ステータスダッシュボード、パフォーマンスグラフとチャート、ヒートマップ、トレース、システムヘルスメトリック、分析、レポートなど、さまざまな形で可視化できます。フルスタックの可視性は、複数のツールを組み合わせて構成することができます。

監視ツールカテゴリ 人気ベンダー

アプリケーションパフォーマンス監視 New Relic、AppDynamics、Dynatrace

インフラ/クラウド監視 AWS CloudWatch、Microsoft Azure、Google Stackdriver

メトリック Datadog、Librato、Keen IO

ログの監視と分析 Splunk、Elastic、Sumo Logic

既に複数の組織が、上記のさまざまなソリューションを使ってITツールのポートフォリオを構築し、インフラストラクチャ全体で何が起こっているのかを深く調べられるようにしています。

PagerDutyのようなソリューションは、ITポートフォリオ内の全ツールから生成された全イベントとアラートを集中管理して集計し、インシデントへのより適切な対応をリアルタイムで選び出します。

何が起きているのかを示せるツールは世の中にたくさんあって、ほとんどのチームは複数の監視とチケット発行ソリューションに投資しています。ここでもっと重要になるのは、大規模なインシデントがビジネスに影響を及ぼすことを防ぐ、あるいはサービスを復旧するため、専門家に対してよりよく事態を理解するために必要なリソースを提供するソリューションです。

さらにその先へ

PagerDutyでは、真のフルスタック可視性は、インフラストラクチャ、アプリケーション、およびサービスの健全性に関するビューだけではありません。インシデント管理、レスポンスオーケストレーション、システムと運用の両方の効率性の視覚化など、他の重要な部分も含まれているため、チームはSLAを継続的に改善できます。ソフトウェアがビジネスと顧客の経験の中心になるにつれて、ITOps、DevOps、開発者、ITリーダー、エグゼクティブ、ビジネス関係者は、インフラストラクチャ全体で何が起こっているかをよりよく把握する必要があります。

インフラストラクチャの真の健全性を評価する際には、人の役割の重要性を忘れることはできません。ツールは常に仕事をしますが、インシデントはそれらのツールのデータを理解できる人々が解決するのです。PagerDutyのオペレーションコマンドコンソールとインテリジェンスアプリケーションは、多数のベンダーの製品から得た状況の推移を単一のビューにまとめ、どんな重大なインシデントが際立っているか、担当者が取り組んでいるインシデントはどれか、どんなイベントが関連性があるかを包括的に把握できるようにします。そしてインシデントへの技術的、ビジネス的対応の両方を調整します。

PagerDutyを使うと、アプリケーション、サービス、インフラストラクチャの健全性を簡単に視覚化し、インシデント対応ワークフローを1カ所で管理できます。