Blog
ブログ

2017年12月19日  (更新日:2022年6月14日)

マイクロサービス時代のモニタリング

迅速性の高まりにつれて増大する複雑さの管理

DockerとDevOps革命のおかげで、マイクロサービスはアプリケーションを構築して展開する新しい方法として浮上しました。マイクロサービスのトレンドを受け入れる理由はたくさんあります。

マイクロサービスを採用する場合は、マイクロサービスアーキテクチャには多くの部品があることも理解しておく必要があります。 インシデント管理に関して言えば、マイクロサービスとモノリシックアーキテクチャの間に重要な違いがあります。 部品が多いほど、アプリケーションとインフラストラクチャの健全性と継続性を維持するために、監視と管理がより複雑になります。

マイクロサービスがいかにIT監視の課題を増やすか、そして増大する複雑さを組織がどのように処理すべきかを探ってみましょう。

マイクロサービスの定義

マイクロサービスは、他のマイクロサービスと組み合わせて完全なアプリケーションを形成する小さなアプリケーションコンポーネントです。 Dockerを使用してアプリケーションをデプロイする場合は、複数のコンテナで構成されている可能性があります。各コンテナは個別のマイクロサービスを実行します。

DevOpsはソフトウェアの継続的デリバリーを奨励しているため、マイクロサービスはこの数年間で普及してきました。管理者はアプリケーション内の特定のマイクロサービスの問題を追跡できるため、マイクロサービスとして配備されたアプリケーションは管理しやすくなります。アプリケーションの特定のコンポーネントへの更新では、アプリ全体ではなくそのマイクロサービスだけを再起動できるため更新するのも簡単です。以上のような理由から、マイクロサービスは継続的デリバリーを容易にします。

2013年にDockerが導入されたことで、マイクロサービスへの関心が高まりました。Dockerコンテナは、マイクロサービスのための便利なビルディングブロックを提供し、モノリシックアーキテクチャに従って設計されたレガシーアプリケーションをマイクロサービスモデルに移植しようとする際に容易な移行パスを提供します。

複雑さ:マイクロサービスのトレードオフ

マイクロサービスを採用している組織は、インフラに追加する複雑さを考慮する必要があります。モノリシックアプリケーションがマイクロサービスアプリケーションに変換されると、管理者が監視すべきパーツが増大します。

たとえば、フロントエンドとデータベースがそのアプリケーション専用の仮想サーバ上で単一のアプリケーションとして実行される、モノリシックなWebアプリケーションを考えてみましょう。このアプリケーションの監視は比較的簡単です。その一部がダウンすると、アプリ全体がダウンします。監視するホストは1つだけであり、対処するアラートも1つだけです。このようなアプリは、異なるポート間の接続やサーバとデータベースのプロセスを監視することで事足ります。

ここで、コンテナのセットとしてデプロイされた同じアプリを考えてみましょう。単一の仮想サーバでアプリケーションを単純なプロセスとして実行する代わりに、フロントエンドとデータベースのレイヤーを異なるプロセスとして実行しているアプリです。Dockerはたくさんのプロセスを起動します。スケールアウトするようなアプリでは、おそらく何百ものコンテナがそれぞれのプロセスを担当するでしょう。コンテナの数はアプリケーションの要求に応じて絶えず変化します。さらに、アプリケーションの統計を収集するなどのタスクを担当するコンテナも抱えることになります。アプリケーションの可用性とパフォーマンスを保証するには、Dockerデーモン自体はもちろんのこと、これらすべてのコンポーネントを監視する必要があるため複雑です。

念のために言えば、私はマイクロサービスが悪いアイデアであるとは全く考えていません。上記の例では、マイクロサービスバージョンのWebアプリケーションは、モノリシックバージョンよりもはるかに拡張性と機敏性が高くなります。スケールアウトの敏捷性には、監視作業を増やすだけの価値があります。

マイクロサービスを効果的に監視する方法

効果的なマイクロサービス監視戦略には、2つの事実に注意が必要です。

明らかなのは、マイクロサービスでは監視すべきコンポーネントが増えているということです。しかし利用するインシデント管理プラットフォームが多数のアラートを処理したり、トライアルを支援したり、適切な人にルーティングしたりする能力を十分に備えていれば、これはさほど大きな問題ではありません。さらに、マイクロサービスではアラートの量がはるかに多くなるため、インシデント管理プラットフォームではアラートノイズを減らす必要があります。関連するアラートをグループ化したり、必要な対応を関連付ける一方、対応不能なアラートは抑制する必要があります。

もう1つ、やっかいな事実は、マイクロサービスが複雑になると、管理者にとってインシデント管理の役に立つ情報の量も増えることです。これは良いことです。モニターするコンポーネントが増えれば、対処すべきデータが増えますが、その余分なデータを活用して問題を特定することができます。モノリシックアプリに関連するアラートは、単にそのアプリのどこかに何か問題があることだけを伝えるため、問題の内容を正確に把握することはあなたの努力次第です。しかし、マイクロサービスでは、個々のDockerコンテナからのアラートにより、管理者は事件の原因となったアプリ内の正確なマイクロサービスを特定することができます。そして、アプリケーションが依存する他のコンテナを中断することなく、そのコンテナのインシデントを解決できます。

マイクロサービスは、インシデント管理チームにチャレンジとチャンスの両方を提供します。インフラストラクチャはより複雑になりますが、インシデント対応をより効果的かつ容易に行うことができます。マイクロサービスのモニタリングの鍵は、モノリシックなアプリの監視とマイクロサービスで構成されたアプリの監視の違いを理解し、マイクロサービス対応のインシデント管理ソリューションとワークフローを適切に配置することです。

続きを読む
インシデント&アラート
2018年8月10日  (更新日:2022年6月14日)

成長の機会を与えてくれたPagerDutyでのインターンシップ

私の名前はJoshua Carnide、Waterloo大学でソフトウェアエンジニアリングを学ぶ4年生です。この記事で、私がPagerDutyのトロント事務所でのインターンシップで得た素晴らしい経験と、それが成功のためにどうに役立ったかをお伝えしたいと思います。

私はPagerDutyのAndroidとiOSアプリケーションの維持と改善を担当するモバイルチームのメンバーでした。このチームの目的は、移動中にユーザーがPagerDutyプラットフォームとシームレスにやり取りできる機能を提供することです。小さなチームだったけど急速に成長していたチームでした。2018年1月に参加したとき、このチームにはわずか5人しかいませんでした。 3ヵ月後、2人のエンジニアリングインターン(私を含む)、製品管理のインターン、5人の常勤デベロッパー、アジャイルコーチ、製品オーナー、エンジニアリングマネージャーの計11人に増えました。 私はここでの4カ月間に想像していた以上に多くのことを学び、信じられない才能を持つ多くの人と出会い、エンジニアとして大きく成長できました。

PagerDutyの人々:多様性と包括性

PagerDutyの人々は驚くべき人ばかりでした。 彼ら自分の製品と彼らが行う仕事について心からの情熱を持っています。ユーザーに最高の経験をしっかりと提供し続けて、その合間に楽しい時間を過ごすために働いています。

PagerDutyは、多様性と包括性を強く信じる個人のコミュニティでもあります。他者との違いを受け入れる環境であり、あなたが本来のあなた自身であることができる場所です。例えばInternational Women’s Dayの日、同社のトロントオフィスでは、SalesforceやProcter&Gambleなどの4人の地元の女性のプロフェッショナルを招いたディスカッションパネルを開催しました。私にとって他のジェンダー指向と比較した女性のキャリアパスについて深く知ることができ、さまざまな職業の女性が直面している現代の課題を知ることができる貴重な機会でした。

PagerDutyにいた時、私はインターンだと思ったことはありません。いつもフルタイムの従業員の一人のように感じました。 インターンシップの最初の1週間に、カリフォルニア州ナパバレーで開催された会社のキックオフ( Company Kick Off :CKO)イベントに参加する特権を得ました! CKOは、シドニー、ロンドン、シアトル、トロント、サンフランシスコのオフィスなど遠隔地の従業員が一緒に来て、PagerDutyの成功を祝い、新年に向けての重要な優先事項に認識を合わせる機会でした。このイベントには多くのソーシャルな機能があり、さまざまなチームや世界各地の人々と出会う機会がありました。サンフランシスコのオフィスで働いているモバイルチームのメンバーにも会いました。会社のさまざまな従業員の背景や経験について学ぶことは本当にクールでした。PagerDutyの一人ひとりがユニークで特別なものをその場に持ち寄っていたのです。

CKOの中のあるソーシャルイベントに参加したモバイルチームと私。 (私は左の後ろの列にいます。)

メンターシップ

インターンシップの初めのうち私は人に助けを求めることを躊躇しました。他の開発者を邪魔(bugging)したくなかったからです。しかし、そのうちにすぐ、彼らが人を助けるのが大好きで助けを求められるのも大歓迎なんだということに気づきました。そして問題を解決するためにペアリングすることがどれほど有益であるかも分かりました。

以前のインターンシップでは、私はAndroidの開発だけを行っていました。 だから私が初めてiOSのタスクを割り当てられたときには、iOSアプリケーションで作業したことがなかったし、Swiftプログラミング言語の経験がないので、随分緊張しました。 タスクはモバイルアプリのライブアップデートに関連するものでした。リアルタイムでコンテンツを動的に更新する新しいアプリの機能です。 この機能の基盤はすでにアプリに入っていて、あまりにも多くのコードを必要ではなかったし、かなり簡単な作業でしたが、どこから始めるべきかはわかりませんでした。

私が助けを求めたときに受けたサポートには驚きました。私はチームのフルタイムの上級iOSエンジニアとペアを組んで一緒にソリューションを作りました。途中で、Swiftの複雑さとiOSフレームワークの基本についても立ち止まり議論しました。その中でPagerDutyアプリについてのベストプラクティスと共通のパラダイムとデザインの決定などの話もしました、

加えて、私は途中で多くの有益な指導をいただきました。私たちのモバイルアプリケーションは、学習曲線が急に上を向く強力なライブラリやテクノロジーを利用しています。それでも私のチームメンバーは、私に手を差し伸べるためには喜んで自分の手を止めてくれました。 時間がをかけてなぜ何かがそのようになったかという理由を説明してくれましたし、何かを改善したり最適化したりできるかどうかを議論することには常にオープンでした。

さらに、私はインターンだったので、何をどうすべきかを決定する際に主導権を持つ(”call the shot”な)ポジションにあるとは思っていなかったのですが、間違いでした。 1か月以上経った後、私はフルタイムのAndroidエンジニアと共同で、テストのしやすさとスケーラビリティを向上させるためにAndroidアプリケーションをどう再構築すべきかという提案書を作りました。チームとして、私たちはどのアーキテクチャを使うかを決めましたが、私たちのアプリケーションにどう適用するのかは決まっていませんでした。 私は私たちのアプリにアーキテクチャを統合する方法の技術的な詳細を書き上げる責任がありました。それは重い責任でしたが、そのチャレンジを進んで引き受けました。他の開発者からの徹底的な見直しを受けてから、この提案は最終的に承認され、現在は私たちのアプリの標準として機能しています。

提案を完全に実行するプロセスには長い時間がかかります。 しかし、我々は、新しいアーキテクチャの基礎とそれで実装されるすべての新機能を定めました。 PagerDutyのAndroidアプリの未来に革命を起こすために私が大きな役割を果たしたと分かるのは素晴らしいことです。

小さなチームで大きなインパクトを

相対的に言えば、モバイルチームはPagerDutyの他のチームと比較してまだ小さいです。 小規模なチームとしては自律的にやれることがたくさんありました。たとえば、私たちのアプリで使用すべきコードアーキテクチャーに至るまで、プルリクエストの形式のような単純なものを理解することは、私たちの責任でした。 私たちは、アプリケーションのリリース時期や頻度を自分たちで決めました。チームはこのプロセスを非常に大事にしています。まずPagerDutyの従業員に新しいバージョンのアプリケーションを配布して、そののちに最高品質のアプリがユーザーに提供されるようにします。 チームの上級エンジニアと数回ペアを組んで、モバイルアプリをユーザーにリリースしました。 この経験から、多数のユーザーにアプリを出荷するプロセスについての洞察が得られました。すべてを円滑に進めるためにリリースを監視する方法を学びました。

成長の機会

PagerDutyには、パイプラインにたくさんのクールなプロジェクトがあり、どれもオフリミットはありません。 私が最初にPagerDutyに入社したとき、私はiOS開発やバックエンド開発をしたいという希望を出しました。 私は両方の仕事をする機会を与えられただけでなく、すぐにユーザーに出荷される重要なプロジェクトに取り組ませていただきました。

新しいことを学べたもう1つの非常に便利な機会は、モバイル・チームの週1回の共同作業セッションでした。そこではチームメンバーが個人的な開発にとって価値のあるものに取り組みます。 何か新しいことを探求し、疑問があるときはいつでもチームの上級開発者のサポートを受けるのは本当に便利なチャンスでした。私はこの時間を使って技術的知識を広げました。Swiftについてより深く学び、さらにiOSフレームワークについて学ぶために小さなiOSアプリケーションを開発しました。

私はアジャイル手法についても学びました。これは私のワークフローを実際に改善しました。 モバイルチームに参加したとき、彼らはScrum Agileメソドロジーを採用していました。 基本的に、これは、チームがスプリントと呼ばれる固定された時間単位で作業を完了するよう計画することを意味しました。私たちのチームにとっては、各スプリントは2週間の長さでした。 各スプリントの終わりに、私たちのチームは一緒になって( れとろすぺくてぃと呼びます)スプリントについて議論しました。何がうまくいったのか、あまりうまくいかなかったのか、プロセスを改善するためにどんな行動が可能だったかを議論したのです。

これらの実践の中で、ボトルネックを特定して修正する方法と、他の開発者と効果的に連携する方法を学習しました。私が最初に会社に入社した時と比べると、自分が高品質の仕事を完成させようとしている間にスループットが大幅に増加したことにはっきりと気づきました。 もう一つのことも気が付きました。つまりPagerDutyが真剣に取り組んでいることは、皆の意見が重要であることと、レトロスペクティブは、各チームメンバーがチーム全体としてどのように改善でき、皆の提案が考慮されたかにというフィードバックを提供する機会であったことです。

未来に

全体的に見て私のPagerDutyでのインターンは最高の経験でした。 インターンシップが終わり、学校に戻ることは辛かったです。幸運にも多くの素晴らしい人と出会って、これからも続くたくさんの関係を築けたと感じています。 私は、自分がインターンシップの過程で獲得したスキルセットが、将来のエンジニアリングの取り組みに役立つと確信しています。 PagerDutyとモバイルチームと過ごした期間は、私にとって決して忘れられない経験です。

PagerDutyで働くことに興味がある場合は、キャリアページ(訳注:米国PagerDutyサイトの応募ページにリンクしてあります)に応募することを検討してください 。

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

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

コールを処理するのは誰?

今日の統合されたデジタルエコノミーでは、ほとんどの企業のITインフラストラクチャはもはやサイロ内に留まっていることはできません。統合の圧倒的なメリットは、新しいアイデアやソリューションを急速に発展させられることです。残念なことは、統合と接続性の向上は自分たちの会社とユーザーを、サイバー攻撃、コンピュータウィルス、インフラストラクチャの問題のリスクにさらすことにもなる、ということです。

組織がシステムを保護し、データと顧客を保護するための対策に投資することが不可欠です。組織は、何かが起こる前に明確なインシデント対応計画を策定しておく必要があります。侵害または顧客に影響を与えるインシデントの検出後には、応答チームを率いる人を探し、誰が関与する必要があるかを決めるのに時間をかけるべきではありません。必要なのは、包括的なインシデント対応計画であり、企業のリーダーシップを含む総合的な対応として事前に用意されていなければなりません。

インシデント対応チームはどこまで包括する必要がある?

インシデント対応チームを組織する際は、ITインフラ、開発、品質保証の担当者を含めるべきです。しかし、他にもその代表を含めるべき部門が多数あります。

会社のリーダーシップ

広報

法務

人事

顧客サービス

危機管理

インシデント対応チームは、インシデントに対する組織の対応を監督し指揮する責任を負うべきですが、リスクを軽減しインシデントが発生する前に予防することも義務付けられます。チームのフォーメーションは、まず適切な対応計画の策定に焦点を当てて、インシデントが発生しないように対策を実施する方向に移行する必要があります。インシデントの予防と対応にさまざまな部門が関与すべき理由と、その方法を決定するために各機能を見てみましょう。

会社のリーダーシップ

インシデント対応チームの創設と成功には、最高レベルの企業リーダーの積極的参加が不可欠です。リーダーの積極性は適切なサポートを可能にし、組織のあらゆる側面にわたるチームとの整合性を確保します。リーダーシップの関与は、インシデントのフォローアップにおいても重要です。インシデントに対応する各リーダーとビジネスの調整は、効果的で迅速に対応するために不可欠です。

広報

インシデントのフォローにおいて、広報担当者が企業とユーザーの主要な接点になります。広報活動の準備の中で重要な責務は、包括的な情報開示方針の策定と、他のチームと連携して、特定の種類のインシデントに対して実行可能なシナリオに沿って対策を実施することです。

法務

法務は、契約や企業責任を担当するチームとして、会社のデータと知的財産の完全性を保護するための法的枠組みを開発する重要な役割を担っています。インシデント発生直後の期間に、法務は会社の責任を決定し、開示および通知に関する法的義務が適切に処理されるようにリードします。

人事

人事には、インシデント対応チームの初期開発段階で、社内から来た人であろうと、組織外で雇用された人であろうと、適切な人材が適切に配置されるようにする責任があります。

人事にはさらに他のチームと協力して、機密データへのアクセスを含む従業員向けのポリシーを策定し、従業員にそのポリシーを教え、必要に応じて従わせる責任があります。

顧客サービス

企業の外向きの顔として、顧客サービスチームは、潜在的な脅威を見つけて報告し、ユーザーへ事態の状況を明確に伝えるという重要なポジションにいます。さらに、既存の情報開示方針に精通し、インシデントがいつ誰にエスカレートされるべきかを理解している必要があります。また、渉外担当者は、外部ユーザーとの作業の中で直面する可能性のあるデータセキュリティ要件と潜在的な脅威を熟知している必要があります。

危機管理

最後に、危機管理チームは、コンピュータセキュリティチームと協力して、リスクが発生する前にリスクを特定し軽減するポリシーを開発し実装します。また、他のチームと連携して脆弱性評価法を開発し、実施し、潜在的なインシデントの早期警告システムとして機能する脅威検出指標を設定して監視する必要があります。

強力な防御が効果的な攻撃を可能にする

インシデント対応はIT部門の責任ではありません。ITは、対応チームで重要な役割を果たしますが、組織全体の全チームの協調的な努力こそが、インシデントに対し統一され調整された対応を可能にします。企業がインシデントを処理するための強力な防衛戦略を策定したら、インシデントが発生する前にリスクを特定し、リスクを軽減することに焦点を当てるべきです。

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

インシデントとアラートの違い

インシデントの定義は、 「システムの運用を通して提供されるサービスの中断、サービス品質の低下、 またはその可能性がある出来事」 つまり、「ディスクの使用率があらかじめ決めたしきい値を上回った」等の、 システム利用者には影響がなくても、サービスの品質が落ちる可能性がある出来事もインシデントとなります。

<<インシデントの例>>

■ システム運用者のインシデント

システムが利用できない プリンタで印刷できない アプリケーションのバグが見つかった システム運用監視ツールが発するアラート(警告)

■ コールセンターやヘルプデスクのインシデント

製品に不具合が出たので直したい 業務に必要なデータを書類にまとめてほしい パスワードを忘れたので再発行してほしい アプリケーションの機能を知らないので使用できない

このように障害だけではなく、課題、質問、要望もインシデントに相当します。 突発的な出来事で、迅速な対応が要求され、即座に対応しなければ被害が広がっていくものは全てインシデントとなります。

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

PagerDutyのスケジュール設定をしてみました

ConfigurationからScheduleを選択します。

「New On-Call Schedule」で新しいスケジュールを追加できます。

まず、 「Time zone」を日本に設定して、Layerを追加していきます。

レイヤーを順番に設定していきます。

レイヤー1では、1人の担当者が日中の時間帯に交互に担当するよう設定してみました。

レイヤー2では、それ以外の時間帯を2名で設定してみました。

最終的なスケジュールは、以下になりました。

簡単なUI操作だけで、柔軟なスケジュール設定ができますね。

また、スケジュールのOverride機能を使うと例外的なスケジュールも組み込むことができるので、非常に便利です。

続きを読む
ベストプラクティス
2017年11月2日  (更新日:2022年6月10日)    |    インシデント&アラート

規制産業のインシデント管理

オンコール状態を保つことは難しく、時にそれは受け入れがたい負担となります。しかし、規制業界 (国の規制により 新規参入や事業拡大が制限されている業界)で働く場合、組織に課せられるインシデント管理への要求は日増しに増大しています。この記事では、規制業界におけるソフトウェア関連のインシデント管理の基本原則について説明したいと思います。

インシデント、規制、コンプライアンス

まず、ソフトウェア関連のインシデントが規制業界で何を意味するのかを簡単におさらいしてみましょう。ソフトウェア開発やIT部門の担当に「インシデント」とは何か定義するように尋ねてみると、大概はダウンタイムやアプリケーションの応答時間の問題に言及するかと思います。しかしこれは、もう一方の重要な要素を見落としている場合があります。それはセキュリティー – 侵入、データ盗難、機密データ保護の失敗などです。

規制産業での「インシデント」という用語は、ダウンタイムやセキュリティー上の問題をはるかに超えた意味を持ちます。それは、組織またはプロダクト、またはサービスを規制の準拠外に追いやってしまうことを意味します。

水道会社にとっての問題を例に挙げると、給水中に大腸菌が入り込んでしまった場合がそれにあたります。銀行でいえば顧客の財務データが失われた場合、病院にとっていえば生命維持システムの重大な欠陥があった場合です。規制遵守が危機に瀕している場合、公共の安全や重大なデータ損失、主要サービスの中断などの事故は、ダウンタイムを伴うものほど深刻になるものです。

コンプライアンス – Stakesとは何か

規制業界に属する組織にとって最も根本的な問題の1つは、適用される規制を遵守する必要があるということです。業界およびインシデントの性質によってコンプライアンスの違反が発生する可能性があります。

罰金、手数料、またはその他の民事上または行政上の罰金 インシデントの影響を受ける組織または個人による訴訟またはその他の訴訟 業界内での作業に必要なライセンスまたはその他の証明書の保留または紛失 業界内または一般の人々の目にある評判の喪失 極端な場合には、責任ある個人の刑事告発、有罪判決、懲役刑

言い換えれば、Stakes(危険度)は非常に高くなる可能性があります。インシデント管理の手続きを裁判官に説明する状況に陥るのは、非常に望ましくないものです。

必要性とベストプラクティス

このような厳しい条件の下でインシデントをどのように管理すればよいのでしょうか。最高のインシデント管理は、コンプライアンスに関わる問題になる前にすべての潜在的なインシデントを処理するという予防対策です。それは実際の状況下では必ずしも実現できないため、法的要件と実用的必要性の両方を満たすインシデント対応計画を立てることが重要です。これを行うには、次の要因を考慮する必要があります。

規制要件とガイドライン イン**シデント管理、予防、対応に関しては、規制当局の要求事項に常に従ってください。これらは業界および関連機関によって異なりますが、大抵は正式なインシデント対応計画、ITインシデント対応チーム、インシデント対応手順およびアクションの正式文書が含まれます。 例えば、HIPAA(Health Insurance Portability and Accountability Act )またはPCIDSS(Payment Card Industry Data Security Standard)の下で運用されている組織には、文書化されたセキュリティレスポンスプランとレスポンスチームが必要です。連邦情報セキュリティ管理法(FISMA) には同様に、連邦機関に対する詳細な事故管理および対応ガイドラインが含まれています。不明点がある場合は組織が対象とする機関と要件を確認し、すべての要件を完全に遵守しているか確認するべきです。 業界ガイドラインとベストプラクティス これらは業界によって異なります。業界全体の専門組織は多くの場合、一連の推奨プラクティスを提供しています。業界に特定のガイドラインがない場合、Common CriteriaおよびCommon Evaluation Methodのドキュメントは、一般的なITセキュリティおよび公衆安全の問題を理解するための有用なフレームワークを提供しています。

一般的な考慮事項

すべての規制産業およびすべての規制の枠組みに適用される基本的な考慮事項がいくつかあります。

識別

障害やその他の誤動作が直接的または間接的にコンプライアンスの問題につながる可能性のある機密システム(アプリケーション、ネットワーク、サービスなど)をすべて特定します。例えば、クライアントの医療記録を含むデータベース、または公益事業のための電力配分を管理するプログラムは、この項目に該当する可能性が高いです。尚、簿記ソフトウェアはこの文脈ではおそらく重要なシステムに該当しません。

プリベンション

インシデント管理の最新トレンドは、システム障害を未然に防ぐことです。つまり、システムの障害だけでなく、障害につながる可能性のある状態についてインシデント対応チームにあらかじめアラートを出す必要があります。セキュリティーに敏感なシステムの場合は侵入を試みる活動やセキュリティーソフトウェア自体のパフォーマンスの低下を示唆する活動である可能性を探る必要があります。公共安全が危機に瀕しているシステムでは、主要メトリックの異常な動作を探る必要があります。言うまでもなく、プリベンションにはデータのフルバックアップ、必要に応じてスタンバイ状態のフルバックアップシステムが含まれます。

問題がコンプライアンスに関わる問題に変わる前に問題を把握するには、インシデント対応チームが完全に同期している必要があります。このような状況では秒単位での対応が重要です。このため、対応担当者を事前に定義してエスカレーションポリシーを明確にし、複数のシステムからのメトリクスへのアクセスを統合して問題を統一的に把握することが不可欠です。

プライオリティ

事実上、既存のインシデント管理のトリアージ(行動順位決定)に別レベルの優先度を追加し、すべてのコンプライアンス関連のインシデントを既存の優先度よりもさらに優先させる必要があります。例えば、簿記システムと在庫システムの両方がクラッシュし、同時に医療記録データベースが天気予報のように不安定になった場合、もし対応できるITスタッフが十分にいなかったとしても、会計担当者と倉庫担当者は緊急チームがデータベースに対応するまで待つ必要があります。また、公共安全に関与している場合は、重大な災害が発生した直後に、重大なシステムを運用する準備ができている必要があります。

これらはとても恐ろしいことのように聞こえるかもしれません。規制当局や裁判官が規制を適切に遵守しなかったと判断した場合、企業が大きなインシデントに対して費やさなければなければならない費用ははるかに高くつく可能性があります。結論として予防的なインシデント管理は、企業にとって自身を守る最高の防衛手段となるはずです。

インシデント対応のプロセスやワークフローを改善するためのリソースを探している場合は、オープンソースのインシデント対応文書と金融サービスソリューションの要約を参照して、PagerDutyがどのように規制対象産業を支援しているか確認してみてください。

※このコンテンツはwww.pagerduty.com/blog/の抄訳です。

2018年4月25日  (更新日:2022年6月10日)    |    DevOps

DevOpsのメインストリーム化

PagerDutyで、私たちはDevOpsコミュニティとITプロフェッショナルが成功するために、どのように支えることができるかを考えて多くの時間を費やしています。私たちは、DevOpsの実践の進化のやり方と理由、実務家に価値を提供する方法、PagerDutyに高い信頼を寄せているコミュニティにどのように役立つのかについて、特に興味を持っています。

このことを念頭に、私たちは最近業界リーダーを対象としたWebセミナーを開催し、最新の実践とDevOpsの将来に関する予測を共有するよう求めました。 APMだけでなく、アプリケーションやセキュリティ監視の世界の視点を取り入れ、デジタル運用管理についての洞察を得ました。このグループには次の人たちが参加しています。

Ilad Rabinovich氏、Datadogの技術コミュニティ担当ディレクター Chris Gervais氏、Threat StackのエンジニアリングVP John Rakowski氏、AppDynamicsのプロダクトマーケティングディレクター Arager Chakrabarti氏、PagerDutyのエンジニアリングディレクター

私たちは、「DevOpsがやがて主流になるか?」とか、「エンタープライズ企業がDevOpsのプラクティスを採用することはできますか?」など、DevOpsの将来に関する多数の質問を検討しました。パネリストは多くのことをシェアしてくれたので、その中から、私たちは以下のハイライトを得られました。

DevOpsはやがてメインストリーム化するのか?

各スピーカーは、DevOpsがやがてメインストリーム化するのかということに関して考えを述べました。

DatadogのIlan Rabinovich氏は、ツールの普及、関連カンファレンス、マーケティング活動の環境全体を上げて、この産業はDevOps用語でいう「ピーク使用量」を達成したとコメントしました。 彼はさらに、誰もが同じ方法でDevOpsの言葉を使用しているわけではなく、真のDevOpsは “CAMS” definition:に定義されれいるような、文化、自動化、定量化、共有などによって証明されると指摘しました。

Threat StackのChris Gervais氏は、普及が遅れたとしてもDevOpsという言葉は確実に主流になると認めました。彼は、多くの組織や特定の種類の企業にとって、DevOpsはその活動のファブリックに組み込まれていることを提示しました。特に、SaaS製品を作っていスタートアップとファームには、DevOpsを一種の基盤となる固有の機能として活用しており、DevOpsのアプローチはまったく新しいものではなく、そうした企業の創業物語の一部になっています。 infrastructure as codeの考えに沿い、素早く進歩したい企業はコミュニティと同じくDevOpsツールの有用性を取り入れています。最近のTechCrunch の記事ではDevOpsは廃れたと宣言されたが、今やメインストリーム化しているはずだ、という冗談も口にしました。

AppDynamicsのJohn Rakowski氏は、DevOpsのメインストリーム化を「はいといいえ」という提案の一種とみなしています。同氏は、他のパネリストと意見を交わすことなく、DevOpsについて聞き取ること無しでは何処へも行けないと同意し、2016年までにDevOpsが主流戦略になるという2015年のGartnerの予測について言及しました。現実はあまり緊密に連携していなくても、Rakowski氏はメインストリーム化できると信じていましたが、 DevOpsの定義に関する継続的な闘争と議論は、特にさまざまな業界や組織にわたって残っています。彼は、エンタープライズ企業のDevOpsとスタートアップ企業のDevOps、DevOpsのメリットを得るために別々のチームを作成している企業などの有意義な違いを見分けました。

Arup Chakrabarti氏は、DevOpsは中小企業にとって「まさにそのままの存在です」と述べています。既存の企業にとって、DevOpsは標準ではありませんが、多くの企業は進化してあります。彼は、遅くて煩わしいことで知られている銀行や通信事業者の中には、DevOpsをポケットに入れて素晴らしい仕事をしていると指摘しました。しかし、彼は、DevOpsコミュニティが企業内でメインストリーム化できるためにはもっと多くの作業を行う必要があることを示唆しています。

エンタープライズ組織はDevOpsプラクティスを採用できますか?

エンタープライズ企業でDevOpsを採用するという問題で、Rabinovich氏は、採用とは技術よりも文化や組織の整合性のことだと感じています。 エンタープライズ企業では、ビジネスユニットやプロジェクトに割り当てられた別個のITチームが行動目標や営業目的などの共有によって内紛調整を対処できるサイロを作成することができます。

Rabinovich氏は「DevOpsの成功した組織は、まず文化と共有に取り組んだ後、ツールやメトリックを使って旅を加速しました。」とコメントしました。彼は市場にはテクノロジー製品を攻撃するために、ツールや、イベントや他のソリューションを販売していますが、文化と共有はメインストリームをもっと集中すべきエリアだと感じています。 DevOpsツールを購入することも一つのことですが、チームが共同の文化を構築していないと、データを共有できても進歩がほとんどなしで、学習も難しくなるとIlanは示唆しています。彼の見解では、CAMSモデルを活用し、共通の目標を特定するために共同作業をすることは、組織の成功への鍵となる道筋です。これは、アライメントと効率性を高め、追加リソースの確保につながる成功を追跡して共有する方法を生み出すからです。

Threat StackのGervaisは、エンタープライズの採用の聴衆からの、DevOpsは上から下、それとも下から上へ押し上げられているのか という質問に対応しました。.Gervaisは、これはただのCIOが DevOpsで “ready set go” というようなケースではなく、その代わりにmiddel outプロセスだと言えます。つまり、DevOpsはITチームの一部だけではなく、何人かの同好の一人一人がビジネス上の問題に集中するときに成長します。ビジネス上の問題に取り組まれる時、チームはDevOpsモデルの実験やテストを行い、従来のエンタープライズプロジェクト計画から外れる可能性のあるメトリクスを確立することでメリットを得られます。 Gervaisは、DevOpsが伝統的なIT組織やPMO組織に由来する場合、本質的に開始能力に制限があることを示唆しています。

Rakowskiの観点から見ると、エンタープライズ企業全体でDevOpsを実装することは、  

「DevOpsの採用はエンタープライズ企業全体でどのように進んでいますか?」などの質問を見て究極の問題とみなされています。ソフトウェアは顧客インタラクションと従業員の生産性を高めルための中心部であり、アプリケーションはビジネス成果を上げるようにします。そのように、技術がビジネスパフォーマンスの第一ドライバーとなっているため、より速いリリースが必須であるという現実があります。 DevOpsを実装しているRakowski州は、エンタープライズにとっての選択肢ではなく、ユーザーにサービスを提供し、ビジネスに価値をもたらすためにITが果たさなければならないことである。

PagerDutyのChakrabartiは、DevOpsの採用は、彼が考えるエンタープライズ企業が直面する最大の課題の3つ:文化、共有、アライメントによって推進されていることを示しています。 Opsチームは安定性に集中し、開発チームはイノベーションと変化に焦点を当てているため、根本的に不安定であり、異種のグループが組織内でサイロを作成します。結果として、彼は、サイトの信頼性と革新のバランスをとるビジネスの成功に焦点を当てた共通の目標を通じて、整合性を確立する強い必要性を認識しています。

マーケット上の雑音を除いて、パネリストはDevOpsがメインストリームかし、2017年以降にエンタープライズに移行していることに同意しているようです。 共有や文化の変革など、採用を推進する重要な要素は、DevOpsイニシアチブの基本要素であり、アライメントは成功と同じ傾向にあります。

このブログシリーズの次回の記事では、「中央オペレーションチームがアプリケーションコードベースに近づくのか」、「セキュリティがDevOpsの運用モデルの一部になるのか」など、さらに重要な質問について検討します。

その間、BrightStudioのデベロッパーズウェブセミナーの2017年の予測と傾向全体をチェックしてください!

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

2020年7月8日  (更新日:2022年6月10日)    |    ニュース&告知

PagerDutyの新機能:仕事のやり方、場所、愛するツールにフィット

by Vera Chen

2020年6月、リアルタイム性を高めるための製品のアップデートと機能強化を発表しました。

私たちは、ユーザーが外出先でのデジタル操作をより良く管理できるように、PagerDutyモバイルアプリのコア機能と美しさを強化することに引き続き注力しています。私たちは、ソフトウェア対応システムからのデジタルデータを利用して、あらゆる信号をリアルタイムの洞察と行動に変換する以上のことを目指しています。ネイティブインテグレーションのエコシステムを継続的に拡張して、チームが必要なときに必要な方法で作業し、対応できるようにすることで、それを実証します。

PagerDutyは、チームが必要な重要な情報とコンテキストを準備していることを確認することで、問題を未然に防ぎ、システムを最高のパフォーマンスで運用し続けることができます。

あなたが今いる場所で仕事をする

PagerDutyを使えば、チームはデスクトップからでもモバイルからでも、どこでもリアルタイムで仕事を管理することができます。インシデント対応者もビジネス関係者も、PagerDutyは認知の負荷を軽減し、重要な瞬間に素早く適切な行動を取れるようにすることを目的としています。

モバイルアプリのロック

PagerDutyでは、セキュリティを非常に真剣に考えており、PagerDutyのモバイルアプリにセキュリティの追加レイヤーを提供しました。ユーザーはアプリからログアウトすることなく、PINロックを有効にしてセッションを短縮できるようになりました。管理者は、ユーザーにPINまたは生体認証のロック解除を要求するように要求するセッションタイムアウトを設定することもできます。この機能がアクティブになると、ユーザーはPINを設定し、ログインし直すだけでPINをリセットできます。

インシデントアクションのメニューの変更

PagerDutyのモバイルアプリは、インシデントの詳細を管理し、伝達する方法を合理化します。ビジネスに影響を与える重要なインシデントが発生した場合、担当者はすぐに対応して解決する必要があります。インシデントアクションのメニューが更新されたことで、インシデントに関する重要なアクションを迅速に実行することが容易になりました。迅速な対応は、インシデントが顧客や収益に悪影響を及ぼす前に迅速に解決し、重要なサービスのダウンタイムを短縮します。

REST APIによるセルフサービスの拡張性

PagerDutyの開発者プラットフォームを介してアプリケーションにリアルタイムのアクションの追加が可能です。このプラットフォームを利用することで、小規模ビジネス向けのウィジェットや企業向けの自己回復製品など、開発者がアプリケーションにリアルタイムワークフローを簡単に構築することができます。

手動タスクを自動化し、より多くの人にリアルタイムワークフローを提供するために、PagerDuty REST APIも拡張していますので、サードパーティやカスタムツールとシームレスにインテグレーションすることができます。

アナリティクスAPI(アーリーアクセス)

アナリティクスAPIのアーリーアクセスが可能になりました。生のインシデントデータと関連するメトリクスを表示することができます。Analytics APIアーリーアクセスプログラムへの参加については、[email protected]までお問い合わせください。

ビジネスサービスAPI

公開されているビジネスサービスAPIやTerraformプロバイダを利用することで、チーム管理者はチームのビジネスサービスを定義したり、プライベートビジネスサービスを作成したり、テクノロジーの問題がビジネスにどのような影響を与えているかについて、全員が同じ言葉を使うことができるようになります。チームごとにビジネスサービスを定義することで、チームを横断した大規模なビジネス中断が発生した際に、誰もが理解できるサービスの全体像を構築することができます。

上はビジネスサービスAPIのデモで、ビジネスサービス作成の例を確認できます。ビジネスサービスAPIを使用してビジネスサービスを削除、取得、一覧表示、更新する方法です。

レスポンスプレイAPI

PagerDutyのレスポンスプレイで、あらかじめ主要なインシデントへの対応を計画しておけば、非常時でも簡単かつ正確、即座に行動することができます。レスポンスプレイは、次のことを有効にします。

大規模インシデントのための迅速かつ正確なマルチチームレスポンスの起動

関連する対応者と主要な利害関係者を特定し、積極的な対応計画を立てる

チャット、Web、モバイルアプリ、モニタリング、カスタムインテグレーションを介したインシデントへのチーム対応のコーディネート

組織全体の利害関係者がアクセス可能な、重大インシデント解決に関するステータスの更新

レスポンスプレイAPIの詳細はこちらで。

アプリイベントトランスフォーマー

PagerDutyとのインテグレーション機能がないツールをお使いでしょうか。イベントトランスフォーマーを使えば、独自のインテグレーションを素早く作成して、PagerDutyアカウント全体に展開することができます。イベントトランスフォーマーは、サーバレスのJavaScript(ES6)関数で、Event API v2標準イベントフォーマットでPagerDutyに送信されたwebhookペイロードを変換するために使用されます。すべてのイベントトランスフォーマーは、新しいアプリフレームワークの一部としてPagerDutyでホストされています。

PagerDutyアプリでのイベントトランスフォーマーの使い方についてはこちらをご覧ください。

愛用のツール:Jira ServerとData Center、Microsoft Teams

私たちはインテグレーションのエコシステムを拡大し続けており、新しいネイティブインテグレーションを追加しました。PagerDutyとJira Server、Data Centerとのインテグレーションは、複雑なワークフローを持つチーム間の同期とコラボレーションを促進します。さらに、PagerDutyは幅広い機能を持つチームの人々とチャネル(エンジニアリング、DevOps、ITOps、カスタマーサービス、マーケティングなど)を正しいインシデント解決プロセスとワークフローに接続し、PagerDutyとMicrosoft Teamsとのインテグレーションにより、リアルタイムのChatOpsを推進します。

PagerDuty+Jira ServerとData Centerのインテグレーション

リモートワークや外出先での作業を効率化する方法を学ぶ中で、日々使用するツールスタックを最適化することにますます注目が集まっています。PagerDuty+Jira Server and Data Centerのインテグレーションにより、以下のことが可能になります。

複数のJiraとPagerDutyアカウントを接続して、組織のスケーリングに合わせて変化させることができます

JiraのIssueサイドバーから強化されたPagerDutyアクションを実行し、PagerDutyを通じてリアルタイムのインシデント対応を促進します

高度なワークフロールールを使用して、Jiraでより多くのことを自動化し、ダウンタイムと停止を減らします

JiraとPagerDutyアカウント間のユーザーを双方向のユーザーマッピングでリンクし、インシデント対応をより良く、より包括的に理解することができます

Video

詳細については以下をご覧ください。

上のPagerDuty+Jira ServerとDate Centerのインテグレーションハウツービデオ

PagerDuty+Jira ServerとData Centerのインテグレーションガイド

Blog:Jira ServerとData Centerのための新しいインテグレーションで、より多くの仕事が可能に

PagerDuty+Microsoft Teamsのインテグレーション

分散型やリモートワークへのシフトの増加により、多くの企業やユーザーが日々の業務を共同作業や管理するためにMicrosoft Teamsに依存するようになってきました。PagerDutyはMicrosoft Teamsとのインテグレーションで、デスクにいてもモバイルデバイスを使った外出先でも、リアルタイムのChatOpsを推進し、どこにいても仕事ができるようにします。Teamsのインテグレーションを有効にすると、以下が可能になります。

Teams内での受任、解決、メモの追加により、重要な対応行動を自動化し、アプリ間の切り替えの必要性を軽減します

グラフやランブック、サードパーティ製ツールへのリンクなど、インシデントの詳細を表示し、より詳細な状況を把握することで、解決までの時間を短縮し、ビジネスへの全体的な影響を軽減します

サービスをチームのチャンネルに接続して、ユーザーとチームのつながりを維持します

下記のPagerDuty Microsoft Teamsの概要でインテグレーションの動作を見ることができます。

video>>>

What’s New: PagerDuty Fits the Way You Work, Where You Are, and With the Tools You Love! | PagerDuty

また、すぐに始めたい方は、下記のPagerDuty Microsoft Teamsインテグレーションのハウツービデオをご覧になることもできます。

video>>>

What’s New: PagerDuty Fits the Way You Work, Where You Are, and With the Tools You Love! | PagerDuty

詳細については、以下をチェックしてください。

PagerDuty+Microsoft Teamsインテグレーションページ

PagerDutyとMicrosoft Teamsのインテグレーションの概要

PagerDuty+Microsoft Teamsインテグレーションガイド

上のPagerDuty Microsoft Teamsハウツービデオを見て、インテグレーションを開始し、インストール、設定、テストを行う

ブログ:PagerDutyとMicrosoft TeamsでリアルタイムのChatOpsの推進

2020年6月のアップデートと機能強化による新機能の利用を開始するには、ナレッジベース、プラットフォームリリースノート、モバイルリリースノートを確認してください。

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

PagerDutyとAmazon EventBridgeを使用したサーバレスイベント駆動型ワークフロー

by Andrew Marshall

2019年7月のニューヨークでのAWSサミットは、AWSとPagerDutyの両方にとってエキサイティングなものでした。AWSチームは、AWSでSaaSを提供するパートナー企業が、顧客が処理するイベントを簡単に挿入できるようにするAWS CloudWatch Events用のAPIセットであるAmazon EventBridgeを公開しました。PagerDutyは、EventBridgeをローンチパートナーとしてサポートすることで、AWSとの長年のパートナーシップを深化させています。AWSベースのクラウドインフラストラクチャを使用するPagerDutyのお客様は、EventBridgeのアドバンテージを利用して、PagerDutyのリアルタイムオペレーションプラットフォームをさらに活用できます。

AWS Lambdaについて少々

AWSがre:InventでサーバレスサービスAWS Lambdaを2014年に発表したとき、多くの開発者はLambdaの大きな可能性について懐疑的でしたが、Cloud Foundry Foundationの世界的な調査によると、22%の企業がすでにサーバーレステクノロジーを使用していることがわかりました。Lambdaが提供する価値はシンプルです。サーバをプロビジョニングせずにコードを実行できます。チームはほぼすべてのタイプのアプリケーションまたはサービスを自動的に実行でき、Lambdaはどんなコードでも実行しスケーリングします。EventBridgeはAWS Lambdaを使用して、PagerDutyなどのSaaSパートナーと提携することで、さらに多くのことを可能にします。

それで、EventBridgeって何?

EventBridgeはAWSの新しいサービスであり、チームは複雑な設定とインテグレーションに貴重な時間を費やすことなく、ネイティブAWSサービスをPagerDutyなどのサードパーティSaaSソリューションに接続するイベント駆動型ワークフローを作成できます。EventBridgeにより、PagerDutyの顧客はAWSがサポートするインテグレーションと機能のすべてを活用できます。

PagerDutyデータのインバウンドソース

EventBridgeを使用すると、PagerDutyユーザーは PagerDuty Eventsによってトリガーされるイベント駆動型ワークフローを簡単に作成できます。AWSコンソール内のインバウンドデータソースが信頼できるため、チームがデータにアクセスするために複雑なWebhookや他のマニュアル設定手順を使用する必要はありません。セットアップが完了すると、チームはPagerDutyイベントデータを使用して、AWSでイベント駆動型のワークフローをトリガーできます。

「AWS EventBridgeとPagerDutyを組み合わせることで、イベント駆動型のワークフローをリアルタイムで生成できます」とCox AutomotiveのリードソフトウェアエンジニアであるEd Kozlowski氏は述べています。「問題を検出すると、PagerDutyは、AWS Lambda関数をトリガーするアラートを生成してランブックを取得し、PagerDutyに詳細をポストできるため、問題をより迅速に解決し、お客様に最高のエクスペリエンスを提供できます」。

PagerDuty+EventBridgeをどう使うか

幅広いAWSサービス製品と同様に、PagerDutyとAmazon EventBridgeでできることには制限がありません。とはいえ、顧客が即時のビジネス価値を実感するために実装できる次のような用途があります。

セキュリティ修復 オープンポートを(AWS GuardDutyを介して)検出するとします。これは明らかにセキュリティリスクであり、適切な対応者に警告する必要があります。PagerDutyとEventBridgeを使用すると、SecOpsまたはオンコールチームへのアラートをトリガーするだけでなく、直接オープンポートへのアクションを実行できます。この追加された修復アクションでは、たとえば、AWS Lambda関数を使用して、Amazon Virtual Private Cloudがポートを閉じます。 実行可能なコンプライアンス違反 同様に、AWS Identity and Access Management(IAM)ロールまたはアクセス許可違反がAWS CloudTrailを介してトリガーされたとしましょう。適切なサービスチーム、管理者、またはSecOpsにこの潜在的なセキュリティやコンプライアンスの問題を知らせてほしいが、警告だけでは修復に役立ちません。PagerDutyとEventBridgeを使用すると、このデータを使用してAWS Lambda呼び出しを自動的に行い、アクセスを完全にロックするか、別の構成変更をトリガーして問題に対処できます。

PagerDutyユーザーが活用できるその他のいくつかのユースケースには、次のものがあります。

リソースのデプロイ:サービスリソースをスケーリングまたは起動して、新しい需要に対応します。 エンドポイントの問題:Amazon Personal Health Dashboardを使用して、エンドポイントの問題に対処するための変更を行います。 カスタマーサービス:PagerDutyがインシデントに対処するときに、新しいSalesforce.com Service Cloudケースを自動的に作成するか、既存のケースを更新します。

AWSエコシステム内でPagerDutyのデータとアラートを実行可能にする準備はできていますか? 詳細については、EventBridgeインテグレーションガイドや、PagerDutyのAWSインテグレーションスイートをご覧ください。

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

2018年12月28日  (更新日:2022年5月19日)    |    インテグレーション&ガイド

アラート対応疲れを減らすためにSignalFxとPagerDutyでソーシャルシグナルを監視する

チームにこう伝えました。「SignalFxで重要なイベントが進行中の場合は通知してほしい」。しかし、システム監視の会社のCTOであるにもかかわらず、進行中のインシデントや潜在的な問題を常に把握するために、適切なアラートを作成することは思ったよりも困難でした。

どうして?

クラウドとオープンソースの登場により、ソフトウェアをより迅速に構築できるようになりましたが、今日の環境は次のようなさまざまな理由から、監視と管理が非常に複雑になっています。

監視するインスタンス数の爆発(ホスト、コンテナ、関数) サービスはまれに「正常動作」というメトリックを発したり、常に変化したりする マイクロサービス構成のため、個別に監視する必要があるサービスの量が増えている

私たちの経験による結論は、誤検知や繰り返される警告の嵐です。アラート疲れはチームがリアルタイムで問題を見つけて解決する能力を妨げるだけでなく、長時間対処されないとチームの士気を破壊し、本来予防可能なシステムダウンをもたらします。

アラート疲れを軽減するための戦略

アラート疲れを軽減することは、自らの焦点を広げることから始まります。きめ細かなメトリックの測定は、トラブルシューティングやフォレンジック分析には非常に役立ちますが、最も効果的なアラートは、アプリケーションの健全性に関する高レベルのインジケーターを構成するシグナルの組み合わせに依存します。特に、次の点を考慮する必要があります。

個々のインスタンスではなく、全体を監視

環境内の個々のコンポーネントのステータスを警告するのではなく、サービスごとまたはグループごとの健全性インジケーターを定義してモニターします。たとえば、サービスインスタンス間のAPI呼び出しの99%が要している遅延時間、ノードの特定クラスタの平均CPU使用率、コンテナのグループのAPIエラーの合計などを追跡します。

1436台のホストのシステムメトリックを集約

固定の閾値よりもパターンと傾向に関する警告

変化する環境に適応できるアルゴリズムで生成された閾値を使用する。分散システムはしばしばミステリアスな方法で動作するため、アラートが発生する前に正しいCPU使用率やAPIエラーの数を判断することは非常に困難です。

単純セッション数と週をまたいだ変化

定期的なパターン(たとえば平日の高トラフィック)や予測的なアラート(次のN日以内にクラスタがディスク領域を使い切るのを警告する)によって、システムの通常の動作と対応を必要とするものを区別できます。

グラフが示す容量のメトリックの傾向

アプリケーションのパフォーマンスの全体的な尺度の定義

さまざまなマイクロサービスのメトリックを組み合わせて、より高いレベルのシグナルとアラートを導き出す。たとえば、ログインユーザーあたりのページ読み込みの数と、API呼び出しの合計に対するAPIエラーの割合です。あるお客様は、すべてのマイクロサービスのメトリックを組み合わせて、デプロイしたバージョンのパフォーマンスが全体的に改善されたかどうかを示すヘルススコアを作成しています。

ソーシャルシグナルの測定

SignalFxでこれらのテクニックをすべて使用していたにもかかわらず、まだ誤検知のアラートが多すぎました。次の点に注意しました。

私はエンジニアリングリーダーなので、サービスオーナーやオンコールエンジニアのように細かいアラートを必要としません。アラートのサブセットをフォローするのは、警告なしにリストがすぐに古くなるため実用的ではありません 私たちはPagerDutyを使用していますが、私が常にオンコールのエスカレーションパスにいるとは限りません 私はSignalFxのステータスページのようなソースを見ることでマイナーな問題をフィルターすることができますが、その代りにインシデント対応に積極的に関わりたくても、アラートが届くのが遅すぎて気付くのが問題が大きくなった後だったということになりかねない

では、他にどのようなシグナルを検出できるでしょうか? 我々SignalFxは#outageという名前のインシデントについてのSlackのチャンネルを作っていました。また、このチャネルは、PagerDutyから重要なアラート通知を受け取って、議論の内容を保存します。運用してみると、重大な問題には多くのユーザーがSlackでコラボレーションし、PagerDutyを介してエスカレーションしているという事実を知ったので、私は#outageで人間の活動に関するメトリクスを収集することにしました。結果は次のようになりました。

私はAWS Lambdaセットを使ってメッセージを照会し分類し(例えば人間かボットか)、それをSignalFxに公開しました。次に、3人以上の人が#outageで5分以上タイピングしていると私に通知する検出システムを作りました。アラートはPagerDuty経由で私の電話に送信され、Slackに直接メッセージが送信されます。

進行中の潜在的な機能停止を警告する

これは驚くほどうまくいきました。誤検知が全くなくはありませんが、その数はほぼゼロになり、関心の高いインシデントは全て通知されました。興味深いことに、いくつかの潜在的なインシデントについてアクティブなアラートとしてではなく通知を受けましたが、エンジニアはいつものサービス観察の中でそれを発見していました。

ハードウェアとソフトウェアの監視は停止しない

最初は、アプリケーションとインフラのメトリクスだけを使用して「完全な」アラートが作成できないことに失望しましたが、これは素朴な期待だったかもしれません。正確なアラートを作成するにはシステム環境を理解するだけでなく、組織がどのようにインシデントに対応するかを知ることも必要です。

私の問題の解決には人間の行動を測定することで十分でしたが、今日のツールの多くが相互運用性とデータ非依存を志向していることを考えると、モニタリングに組み込む可能性のあるシグナルはたくさんあります。

インシデント管理と問題検出を統合する

リアルタイムのビジネスはリアルタイムの運用インテリジェンスを必要とし、今日のテクノロジーは従来の監視ツールで処理できる量よりもはるかに多くのデータを送信します。SignalFxは環境内の各コンポーネントからのストリーミングメトリックを収集し、数秒で分析とアラートを提供するため、問題が顧客に影響を及ぼす前にそれを見つけて解決することができます。

SignalFxとPagerDutyを使用すると、SignalFxでアラートがトリガーされたときにPagerDutyでインシデントを自動的に開くことができます。アラートに応じて異なるエスカレーションポリシーにマップし、正常に戻ったときに解決されたインシデントを自動的にマークします。

SignalFxは、組織が重要なシグナルをリアルタイムにあらゆる規模で監視するのを助け、かつてないほど迅速に革新することができるとの自信を持っています。

Arijit MukherjiはSignalFxのCTOで、システムの監視に情熱を傾けています。Facebookのメトリクスソリューション(ODS)のオリジナル開発者の一人であり、その後もFacebookのネットワーキングツール、データビジュアライゼーション、その他のインフラ監視ソフトウェアの開発を管理しました。10年以上にわたり監視の領域に重点を置いていましたが、20年以上にわたる彼の多様なキャリアは、IPテレフォニー、VoIP会議、ネットワーク仮想化にも及んでいます。

GET STARTED

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

2018年10月3日  (更新日:2022年5月19日)    |    ニュース&告知

PagerDuty、Atlassianユーザーのためのデジタルオペレーションを推進

IT Operations、DevOps、およびDeveloperチームは、PagerDutyの300以上の統合を利用して、どのツールスタックを使用していても、エンドツーエンドのリアルタイムデジタル操作を強化します。 PagerDutyの顧客はすべての規模、業界、およびデジタルでの成熟に対応しているため、通信、APM、ITサービス管理(ITSM)などのニーズにどのツールを使用しているかについて常にお客様にお聞きしています。

今年の初めに、PagerDutyはITSMソリューションとしてServiceNowを活用しているチームのための新しい統合を開始しました。 Atlassian Suiteとの包括的な統合を開始することができ、AtlassianユーザーはPagerDutyのリアルタイムデジタルオペレーションの機能を日常業務に追加することができます。

今月(2018年9月)のバルセロナでのAtlassianサミットでは、PagerDutyチームは共通のお客様のうち3000人を超える方々と交流する機会を得ました。 Atlassian Suiteの最新のプラットフォームとのインテグレーションは、お客様からのフィードバックを共有した結果として構築されたものです。Atlassian Summitは、これらを発表するのに理想的な場所でした。 PagerDutyとAtlassianは、Jira Software、Jira Service Desk、Jira Ops、およびBitbucketの双方向インテグレーションの新しいセットを組み込むように、 パートナーシップを拡大して深めました。これによりチームはリアルタイムでアクションとコラボレーションを行うことができます。 さらに、PagerDutyのイベントインテリジェンス機能は、デジタル信号と人間の反応行動の両方を組み合わせて、Jiraにさらに深いコンテキストを提供し、Atlassianユーザーの生産性を向上させます。

Atlassianユーザーは、すでにJira SoftwareやJira Service Deskなどのようなシンプルな製品を使うのが大好きです。これらの新しいインテグレーションにより、よりスマートで効率的に作業することがさらに容易になりました。 PagerDutyは、Atlassianユーザーが本物のリアルタイムオペレーションを自分たちのデジタルでの仕事に活用できるようにし、さらにAtlassian Suiteだけでは本来は利用できない機能を追加できるようにします。

リアルタイム運用センターでできること

PagerDutyを使うと、Jira SoftwareとJira Service DeskでPagerDutyとの双方向同期で問題や重要なサービス要求を処理し、インシデント解決を加速できます。 こうした柔軟性は、お客様との会話で常に出てくるテーマでした。私たちは、この新しいレベルの機能性をお客様と共有できることを嬉しく思います。 全体として、PagerDutyのAtlassianとのインテグレーションにより、PagerDutyを使うチームは、デジタルオペレーションプロセス全体で問題の検知、対応、通信、改善をより効果的に行うことができます。 AtlassianユーザーのためのリアルタイムIT運用のハブと記録システムとしての役割を果たすことで、PagerDutyを使うチームは、Atlassian Suiteの中で好きな方法で作業することができます。クラス最高のModern Incident Response、Event Intelligence、 Analytics 、 Visibilityといった製品に対応しています。

すべての信号、より少ないノイズ

Atlassianユーザーは、PagerDutyプラットフォームが提供する300以上の監視、コラボレーション、開発、セキュリティ、およびその他のツールとのインテグレーションに期待することができます。 PagerDutyのイベントインテリジェンス製品は、Atlassianユーザーのためのゲームチェンジャーですあり、チームの効率性をさらに高めます。機械学習を利用して信号からノイズをカットし、チームの時間を節約し、あなたの組織にとって本当に大事なことに集中できるようにします。 また、Jiraとの同期を維持することで、チームの生産性が向上します。 この豊富なコンテキスト情報をAtlassian Suiteに追加することで、ユーザーはデジタルオペレーションのライフサイクル全体にわたって効率を上げることができます。

自動化されたリアルタイムOpsが可能に

データは、適切な人の手元にある場合にのみ役立ちます。 これを念頭に置いてPagerDutyプラットフォームは構築されました。新しいAtlassianのインテグレーションも例外ではありません。 PagerDuty + Atlassianを使うと、リアルタイムで、適切なコンテキストで、適切な人と交流できます。 インシデントに関するバックグラウンド情報を検索する必要はありません。それは自動で用意されます。ユーザーはPagerDutyとJiraの間で、豊かで実用的なインシデントを自動または手動で同期できます。 このような柔軟性により、チームはAtlassianのツールスタックとSlackのようなChatOpsツール全体でワークフローの統合を調整できます。

無料で試してみてください。簡単に始められます

PagerDutyとAtlassianの両方のユーザーは、それぞれのソリューションをどのように簡単に(そして素早く)始めることができるかをすでに知っています。では、私たちの統合ソリューションは他と何が違うのでしょうか? PagerDuty + Atlassianは簡単に設定でき、製品間で同期し、ビジネスに合わせて拡張できます。チームがどこでどう働いていても適応するインテグレーションを提供することで、共通のお客様がJiraとAtlassian Suiteを合理的に利用できるようにしました。 Atlassianを試用するチームは、PagerDutyプラットフォームとの統合により、イベントインテリジェンス、300以上の監視ツールとの統合、オンコールのローテーションとスケジューリング 、冗長性のある通知の配信など、スAtlassian Suiteだけでは使えない機能を活用できます。

新しいAtlassian Suiteとのインテグレーション Jira Service Desk

Jira Service Deskの統合により、エージェントは重要な要求に対してオンコールのレスポンダーに従事し、通知することができます カスタマーサービスエージェントのビジネスコンテキストとサービスの健全性の可視化 PagerDutyのサービス要求状態、優先度、および注意事項の双方向同期 Jira Service Desk UIに表示されるサービス要求のエスカレーションに関する詳細情報

Jira Software

Jira Software( Cloud / Server )はPagerDuty Event Intelligence Awareなもので、デジタル信号と人間の対応行動の両方を見て、より上流のコンテキストを提供します PagerDutyからJiraにフィールドをマップする機能を含む、PagerDutyで識別された問題とインシデントの詳細をさらに詳しく提供 問題のステータス、優先順位、および注意事項に関するPagerDutyとの双方向同期 問題をエスカレートし、Jira Software内からのをオンコール中のレスポンダーを呼び出せます PagerDutyのインシデントをJiraに自動または手動で同期できます

Bitbucket

ビルドやテストの失敗に素早く対処して、パイプラインをグリーンに保つ コミットによって障害が発生した場合は、すぐにエンジニアに知らせて対応させる PagerDutyと Bitbucketとの統合の詳細

Jira Ops

自動的に、またはボタンを押すことでJiraインシデントを開く 課題(Issue)のステータスのPagerDutyとの双方向同期 問題をエスカレートし、Jira内からオンコールのレスポンダーを呼び出せる PagerDutyがJira Incidentタイムラインと統合されます PagerDutyと JiraOpsとの統合の詳細

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

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

ITOpsチームのためのインシデント管理:集中化を学ぶ

ITOpsチームはインシデント管理を集中化できますか? ITOps部門で仕事をしている人なら、その質問に対する最初の答えは、はっきり「いいえ」かもしれません。

結局のところ、ITOpsはあまりにも幅広く多様なことに責任を抱えているため、インシデント管理に関してはすべてを一つの傘の下に置くことはほとんど無理と思われるかもしれません。サーバの管理、デスクトップPCのプロビジョニングからヘルプデスクのサポートまで―業者の選定や管理には言及していませんが、ITOpsチームはすべてそれを行います。

これは、ITOpsを組織の他のほとんどの部門と大きく違うものにします。プログラミング部門の場合は、コードリポジトリを使って開発プロセスとバグ管理プロセスを集中管理できます。 営業部門なら、Salesforceのような集中型プラットフォームを使用して、製品と顧客の連絡先を管理できます。でもITOps部門ではそうはいきません。非常に多くの異なるタスクをカバーしているからです。

ここでは、ITOpsの集中インシデント管理が単なる夢物語だとは限らないことをお伝えします。確かにITOpsは非常に多くの多様なジョブを処理しているため、1つであらゆる組織の問題を監視して対応できるプラットフォームはありませんが、インフラストラクチャ全体のインシデントを管理は一元化できます。

どうやって? その答えは、ITOpsワークフローのさまざまな要素を統合できるインシデント管理ツールを使うことです。

監視サービスを最大限に活用する

ITOps自体が集中化されていない場合でも、ITOpsチームがインシデント管理を集中化する方法について基本を説明しましょう。

あなたが中小企業のITOpsのプロフェッショナルであれば、3つの主要なインフラを把握しておく必要があります。1つ目は、ローカルファイル共有をホストしたり、いくつかのWebサイトを提供するために使用する社内サーバです。 2つ目はデータをバックアップしているパブリッククラウドです。 3つ目はローカルのワークステーションで、常に稼働状態にして、オンプレミスとクラウドのサーバに接続している必要があります。

このインフラの各部分のインシデント管理を計画するのは難しいことです。一部の監視システムは、ベアメタルサーバ、クラウドインフラストラクチャ、そしてPCを等しく良好にサポートできると主張しているものがあります。しかし、もしそうなら、おそらくどの分野にも特化した機能を持っていないのでしょう。そういうシステムは、特定の種類のインフラ向けに設計された高度な機能を持たずに、一般的な監視機能だけを提供しているのです。

ですから、単一の監視システムでカバーしようとするのではなく、各インフラの特質に合わせて調整された監視サービスを複数組み合わせて使う方がよいでしょう。クラウドの場合は、AWS CloudWatchなどのクラウドセントリックの監視システムを使えば最大の効果を引き出せます。 SolarWindsは、オンプレミスのデバイスやローカルネットワークに便利です。 Splunkのようなものを使えば、多くのデバイスが吐き出しているすべてのログデータを分析することもできます。

すべてを統べるたった1つのインシデント管理ツール

ここで紹介した各監視プラットフォームには、アラートまたは通知システムが付属していますが、通知は必要十分なほどロバストではない可能性があります。たとえ十分ロバストであっても、ITOpsチームは、いくつかの異なるプラットフォームからアラートを(しかも異なるフォーマットでいろいろな種類のコンテンツを)一度に受け取りたいとは思いません。そんな状況では、適切なアラートが適切な人に適時届いているかどうかを確認するのはまず無理です。

同じく重要なことに、通知をチームにどのように配信するかを集中管理することもできます。たとえば、監視サービスの中には、SMSアラートをそのサービスだけでは出せないものがあります。通知を必要な形式に変換できる集中管理型のインシデント管理プラットフォームとこれらのサービスを連携させれば、必要に応じて管理者の電話に通知を転送できます。

最後に、集中管理されたインシデント管理ソリューションを使うと、冗長なアラートを回避できます。ネットワークが過負荷になると、ネットワークスイッチを監視しているサービスからの通知だけでなく、サーバ上の監視スタックまで通知を出し始める可能性があります。

同じ問題に起因する複数のアラートを受信すると、チーム間で混乱が起こり、対応にかかる時間が長くなります。これとは対照的に、集中管理されたインシデント管理では、監視システムごとではなく、インシデントごとに通知を受け取ります。したがって、ノイズは少なく、何が起きているのかはすぐに分かります。

通常、ITOpsワークフローにもう1つのツールを追加すると、余分なだけに見えるかもしれません。多くの状況ではそうかもしれませんが、インシデント管理の場合、PagerDutyのような通知を集中管理するソリューションを実装することで、既に導入済みの監視ツールからさらに多くの価値を引き出せます。

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

2019年8月26日  (更新日:2022年5月19日)    |    DevOps

DevOpsは買えません

DevOpsへの移行は、どこから始めればよいのかわからない多くの組織にとって、大変な作業になる可能性があります。私は最近、どんなソリューションが市場に出回っているかを知るために、いくつかのDevOpsの評価を読んでみました。それはDevOpsを完全に採用している組織から、まだ始めたばかりの組織までありました。評価の中には真の価値をもたらし、文化や方法論に関する記事にリンクしているものもあれば、DevOpsのすべての夢を実現するためのツールを提供してくれるというものもありました。

DevOpsの過程では、ユーザーがサービスを継続的にデリバリーし、自動化し、サービスを監視することを可能にするソフトウェアとしてのツールは不可欠です。ただし、DevOpsは製品ではなく、ツールだけではDevOpsの価値を十分に理解するために必要なプロセスを得ることができません。DevOpsでは人が最も重要です。人がいなければ、DevOpsを完全に実現するために必要な考え方や文化を構築することはできません。

DevOpsで勝つのではなく、チャンピオンになる

私は最近PagerDutyのCEOであるジェニファー・テハーダと勝者とチャンピオンの違いについて話をしました。彼女は勝利の素晴らしさを語りました。トロフィーやタイトル、もしそれが宝くじなら数百万ドルが手に入ると。しかし、大きな絵で見ると、勝利は短期的なゴールに過ぎません。対照的に、チャンピオンになるには、長期的な成功や成果に焦点を当てることが必要です。この会話で、DevOpsを採用している組織に同じ原則をどのように適用できるかについて考えさせられました。

DevOpsツール関連の私のお気に入りの1つは、XebiaLabs社のDevOpsツール周期表です。

表に示されているように、DevOpsカテゴリーには多数のツールがあります。しかし、ツールを購入することによって組織が「DevOpsに変貌する」という話を見たり聞いたりすることが多すぎます。先に述べたように、ツールはDevOpsへの過程の重要な部分ですが、ツールだけではDevOps環境は構築されません。DevOpsチームを適切に機能させるためのすべての要素(コラボレーション、自動化、オーナーシップ、サイロの解体、プロセスの定義、継続的改善、継続的デリバリー)を考慮する必要があります。

ツールの購入を決断することは正しい方向への大きな一歩ですが、もっとも重要なのは、決定の背後にある「なぜ」、つまり最終目標を定義することです。そのために、もう一度チャンピオンの考え方を検討しましょう。

たとえば、オリンピックの水泳金メダリスト、マイケル・フェルプス選手を見てください。フェルプスは史上最も称賛されたオリンピック選手であり、彼は39の世界記録を保持しています。フェルプスは1、2勝するどころか、20勝でも止まりませんでした。彼はチャンピオンになることを目指しました。これはすべて、コミットメント、実践、そして目的とする最終状態に集中することによって成されました。

DevOpsの定義

DevOpsには何百もの定義がありますが、ほとんどの人はDevOpsレポートで概説されている次の基本原則に同意することができます。

「DevOpsは、チームがより効率的に作業し、優れたソフトウェアをより迅速に提供できるように、文化とプロセスを構築することを目的とした一連の原則です」。

文化やプロセスはクレジットカードで変更することはできません。ツールを使用すると、組織はより優れたコラボレーション、自動化、継続的デリバリーを実現できます。しかし、正しい考え方と選択がなければ、ツールの全機能が達成されない可能性があります。

例としてSlackを取り上げましょう。新しい会社に転職した私の元同僚は会議に出席していました。彼は、Slackのチャンネルを作ってコラボレーションすることが、チームをDevOpsに変えるために素晴らしいと言うのを聞きました。Slackが彼らのすべてのコミュニケーション問題を解決するだろうと彼のマネージャーは確信しました。しかし、Slackを採用してから6か月後でも、マネージャを含めチームの大半がまだSkypeを使用していました。Slackは、製品をより早く市場に投入するために使用されるツールというよりは、ビールの醸造について話すための場所になったのです。問題はSlackではありませんでした。それはチームと組織の参加の不在、そして製品の全機能に関する知識の欠如でした。

ツールとベストプラクティスをチームと短期、長期の目標の達成にいかに機能させるかが、DevOpsチャンピオンとしての我々が話すべきことです。たとえば、チームや組織の全体の目標は何ですか? 目標が特定されたら、主要なステークホルダーからどのようにして賛同を得るのでしょうか。合意が成された後、どのようにしてソリューションを実装しますか?

組織変更

変化は多くの組織や個人にとって困難であり、意味のある変化は一晩では起こりません。人と組織がどのように変化を成し遂げるかを理解することは重要です。

Kotter 8-Step Process for Leading Changeが提唱するのは、最初のステップで変化の必要性を明確にし、すぐに行うべき理由を考え、小さなことから始め、勝とうとする前に内部にいるチャンピオンを見つけて育てるということです(この場合の変化はツールの購入)。

組織内の人々が問題を認識していない、またはより良い運営方法が存在することを認識していない場合、チームメンバーの賛同と新しいアイデアを採用し行動を起こすように動機付けることは困難です。もしかすると現在のプロセスが十分であるため、人々は現在の状態に完全に満足しているかもしれません。または、少なくとも現在の状態が既知である可能性があります。しかしながら、チーム全体がうまく機能し、より早く、より機敏な方法で彼らの共通の目標を達成するためには、最初に新しいメカニズムを導入しなければなりません。

DevOpsチャンピオンになる方法

DevOpsの世界でチャンピオンになることは、勝利を超えて進むことを意味します。それは、チームと組織構造と文化を深く掘り下げて、ツールの範囲を超えた問題を特定し、他の人と協力して、明確な結果につながる必要な変化を受け入れることを意味します。つまり、最初に戻って最終の目標を定義する必要があります。以下はあなたが始めるように頼むことができる簡単な質問です。

あなたのコアバリューは何ですか? なぜあなたはもっとアジャイルな会社やチームになろうとしているのですか? あなたのチームや組織はどんな障害に直面していますか? ツールやプロセスは何を達成するのでしょうか? 人々はどのようにしてコミュニケーションやコラボレーションをしていますか? サイロはありますか? それはなぜですか? あなたはどのように顧客を擁護していますか? 従業員は権限を与えられていますか?

最終状態を定義したら、志を同じくする他の人をチャンピオンチームの一員にし、達成しようとしていることを見失なわないようにしましょう。1つのチームやテスト環境から始めるなど、変化を始めるときはスモールスタートを忘れずに。小さく始めて勝利を築くことによって、内部のチャンピオンは彼ら自身をクリエイトし​​始めるでしょう。

覚えておいてください。企業は熱心にDevOpsを売ろうとしています。しかし、結局のところ、DevOpsは製品ではありません。それは、自動化、コラボレーション、人、そしてプロセスの方法論と考え方なのです。

*この記事のオリジナル版は、opensource.comで以前に公開されたものです。

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

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カ所で管理できます。

2018年3月7日  (更新日:2022年5月19日)    |    ベストプラクティス

いかにして優秀なエンジニアになるか パート1:レバレッジの向上

PagerDutyで私達は個人としてもチームとしても日々勉強に励んでいます。具体的には、事後分析、コードレビュー、過去の見直し、SlackやJIRAでの議論、ヘルスチェック調査などです。さらに、インタレストグループに参加したり、スプリントレビュー、テクニカルトーク、ブログを読いんだり書いたりする機会もあります。

エンジニアとして、私たちは非効率なコードをリファクタリングし、技術的な欠陥に対処し、ワークフローを改善しようともしています。このように多くの仕事をしている(これとは別のスクラムチームでやっている製品やインフラストラクチャの仕事もある)ので時間をどのように管理するかが重要です。たとえば、どのプロジェクトが他のプロジェクトより優先されるべきか、その理由は何か? 目標に向かってより効果的に進めるため、私たちは何をすべきか?

これらの質問に答えるには、当面の仕事のレバレッジを評価する必要があります。Edmond Lauの効果的なエンジニアによるとレバレッジとは「投下された時間当たりの生成された価値またはインパクト」というシンプルな方程式で定義されています。

言い換えれば、ハードに働くことは効果的に働くことと同義ではありません。それは仕事が生産的なのか、ただ忙しくしているのかの違いです。それを知るための別の方法は、エンジニアリングのROIです。私たちが取り組むべき仕事は無限にありますが、私たちの時間とリソースは限られています。効果的であるということは、最小の努力で最大の価値を生むものに取り組むことを意味します。「結果の80%は20%の労力から生まれる」―Pareto Principleとも呼ばれる80-20のルールが当てはまります。

どうすればレバレッジを高めることができるか

元IntelのCEOであるAndrew Groveは著書「High Output Management」で、レバレッジの総量―時間単位で生産する価値―を高めるためには、3つの方法しかないとしています。

一定の活動を完了するのにかかる時間を短縮する 特定の活動のアウトプットを増加させる レバレッジがより高い活動に移行する

日中は、会議、メールのチェック、Confluence/コメント/ブログの読み書き、Githu/Confluenceへのフィードバック、Slackディスカッションへの参加、デザインスプリントなど、さまざまな活動が行われています。しかし、あなたが何をしているのかに関わらず、あなたのレバレッジを向上させるために次のことを自問してみましょう。

どうすればこの活動を短時間で完了できるか どうすればこの活動によって生み出される価値を高められるか より高い価値を生み出せるものが他にあるか

以下にいくつかの例を示します。

ミーティング

会議をより効果的にするために、以下の質問について考えてみてください。

この会議に1時間かける必要があるか。30分で済ませられないか。それとも15分内のほうがいいか 会議の目的を全員が理解しているか。出席者は何か準備する必要があるか。彼らは事前に何かを読んでおくべきか この会議は必要なのか。Slackやメールですませられないか

電子メールとSlackのチェック

メールとSlackの設定は個人ごとに異なります。メールのチェックと返信に価値があることは否定できません(Slackのメッセージを読み、アップデートし、コラボレーションすることも同じ)。だが、これらはどんな点でそのリターンを低下させているのか。言い換えれば、これはいつから私たちの生産性の阻害要因になったのでしょうか。

1日を通して絶えず割り込みがかかる中で、この競り人の速さでコードを書けるマインドセットを持つことは難しいかもしれません。たとえば、私はコミュニケーションツール(メール、Slack、JIRAなど)で頻繁にチャットをしながら、Command + Tabでアプリケーション間を行き来したり、Chromeののタブからタブへとスイッチしたり、そしてコードを書いたりと、落ち着かない働き方をしています。しかし、私は正面を向いてロックインし、レーザーのように集中できる割り込みなしのコーディング時間―私が言うところのディープワークを、1日に少なくとも2〜3時間取れるようにしています。

Deep Workの著者であるCal Newportは、それを次のように定義しています。

「途切れのない十分な集中力で行われる専門的な活動は、認知能力を限界まで押し上げる。その努力は新しい価値を創造し、スキルを向上させる。それは簡単には真似できない」

私はまた、心理学者Mihaly Csikszentmihalyiによって造られたflowと呼ばれるコンセプトを聞いたことがあります。flowを経験した人々は、flowのことを「何の努力もせずに、時間の感覚や自己の存在、自分の問題も忘れるほど集中できる状態」と表現しています。

ディープワークをしている時、私はSlackのスヌーズ機能を使用しています。これで設定した時間は通知が抑制されます。その後、きりのいいところで何も起こっていないことを確認するため定期的にSlackをチェックします。

エンジニアは最大限仕事を頑張って、効果的な結果を果たしていると私は信じており、人には1日に少なくとも1時間か2時間は仕事に集中し、より生産的であるかを確認するよう勧めています。この時間を通常の集中していないコーディング時間と混同しないでください。理想的には、私たちは一日中コードを書くべきですが、散漫で集中していないコーディングと中断のないコーディングとは違います。私がディープワークと言う時は、途切れることのないコーディングを指します。

あなたが作業している現在のJIRAチケット

Jiraチケットがすでにプロダクトオーナーによって優先順位付けされており、ストーリータイムとスプリント計画プロセスを経ていると仮定すれば、それをもう一度見て、そのレバレッジを高めることができるかどうか考えましょう。次の3つの質問でそれをチェックしてみましょう。

どうすればこの活動を短時間で完了できるか 既存のライブラリを利用できるか。エンジニアにとって最初からスクラッチでコードを書くことが魅力的であることは私も知っています。 どうすればこの活動によって生み出される価値を高められるか より高い価値を生み出せるものが他にあるか

現在の目標やリリースのためもっと重要な作業が必要なのか。このような状況ではMVP (最小限の実行可能な製品)を考える―初期のフィードバックを収集しようとしているときに、最初からこのファンシーな最適化が本当に必要なのだろうか。リリース可能な最小スライスは何か。リリースにおける80-20とは何か。しないでいいのは何か。どのようにして価値を下げることなく範囲を縮小できるのか。

忙しい仕事に巻き込まれるのはよくあると思います。しかし、私は正しい質問を自分に問うことを覚えました。そうすれば効果的に仕事をして生産性を高めることができるでしょう。

次回は優先順位付けの方法についてより詳しく説明します。お楽しみに。

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

2017年12月13日  (更新日:2022年5月19日)    |    インシデント&アラート

オンコールエンジニアのベストフレンド

オフィス に戻って、一晩中サーバ がダウンしていたことを知った経験がありますか。また、その時にアラート通知を受ける方法がなかったのですか。 だとすれば、モバイルインシデント管理が必要です。 ほぼすべての人のポケットにスマートデバイスを持つ現代社会で、インシデントが発生したときにスマートデバイスを活用せずに自分が無力だと思い込むのは残念です。

モバイルインシデント管理の重要性 計画外のインシデントはいつでも襲ってきますが、その時、モバイル端末はインシデント管理の重要なギャップを埋めます。 多くのインシデントは、チームメンバーがオフィスにいないときに発生します。 チームメンバーが眠っているときにも起きます。 インシデントは、こちらの都合を待ってはくれません。

そのため、モバイルインシデント管理が絶対に重要です。 モバイルインシデント管理では、あらゆるデバイスから、外出先でインシデントを解決する方法を提供します。 アラート、統計、要約、タイムライン、ログなどの概要を表示します。 誰がオンコール待機かを知ることができ、オンコールのチームメンバーは、選択したデバイスを介してリアルタイムで通知を受け取ります。 その他にも、チームの割り当て、どこからでもコミュニケーションやコラボレーションを行う機能、他のアプリと簡単に統合できる機能など、便利な機能があります。

モバイルアドバンテージ 一見すると、モバイルインシデント管理は「モバイル用のアプリならありますよ」と言いたがるトレンドに沿っただけのものに見えます。しかしモバイルインシデント管理の利点は無視することはできません。

インシデント管理アプリケーションをスマートフォンまたはタブレットにインストールすることは、デバイスにすべての機能が統合されていることを意味します。 PCと比較して、スマートフォンはより便利な通信手段です。単独でデータを持てますし、電話をかけたり、電子メールを送信したり、テレビ電話をかけたり、緊急サービスに知らせることができます。ラップトップやデスクトップをいつも持ち歩いていなくても、おそらく電話ならいつもお手元に置いてるはずです(またはベッドサイドに)。インスタントメッセージアプリ、作業ファイルなども内蔵しているでしょう。これは、それを4時間いつでも問題を通知するのに理想的なデバイスにします。さらに、インシデント管理アプリケーションはすべての電話連絡先と統合されるため、適切な連絡先情報で適切な人物に自動的に連絡してインシデントを解決しやすくしてくれます。また、アプリのダッシュボードやサマリーに重要なインシデントがあるかどうかを素早く判断して把握することもできます。この方法で、後回しにするインシデントを再割り当てまたはスヌーズすることができます。

インシデント管理アプリケーションを持ち歩けば、問題を見逃すことはありません。あなたがいない間に何が起きるかを心配せずに机を離れることができます。モバイルインシデント管理は、インシデント管理の強力な自動化と、いつでもどこでもあなたに届くフェールセーフを提供します。

DevOpsにとっての利益は?

DevOpsを実践する場合、チームがモバイルインシデント管理アプリケーションを使用することは、多くの利点があります。応答が必要なリアルタイムの問題についての情報を得られることは非常に強力です。常に準備を整え、問題を迅速に解決することができます。これにより、イノベーションとコラボレーションにより多くの時間を費やすことができます。モバイルインシデント管理では、Dev、QA、およびOperationsのすべての人をインシデント管理に確実に同列に関与させていることを確認します。

このコラボレーションは強力なものとなり、インシデントをより効率的に解決するのに役立ちます。チーム全体が常にインシデントを追跡する能力を持っていることで士気が高まります。これにより、多くのプレッシャーが軽減され仕事に集中できます。そして、誰もが開発中のコードについてコールを受けられるようにしておくことは、開発者がより良いコードを生産することを可能にします。これにより、開発プロセスのスピードアップと品質が大幅に向上します。

オンコールエンジニアのベストフレンド オンコールエンジニアは、救急サービスの一次対応チームのようなものです。モバイルインシデント管理は、仕事をずっと簡単にします。リアルタイムにインシデントに適切なアクションをとるためのソリューションを提供します。タイムライン、ログ、対応者の割り当てなど、インシデントを解決するために必要な機能をすべて備えています。モバイルインシデント管理アプリケーションを使用すると、オンコールのエンジニアはインシデントの重要度を迅速に分類して、優先順位や影響を受けるサービス、外部向けの対応を把握し、モバイルデバイスからエスカレート、共同作業、解決、またはスヌーズを直接行うことができます。これにより、誰も時間を無駄にすることがなくなり、オンコールのエンジニアは必要な時に、そして必要なときに対応できる人を募ったり、インシデントを再割り当てすることができます。インシデントがはるかに迅速に解決されるため、不要なエスカレーションが最小限に抑えられます。

PagerDutyのモバイルインシデント管理アプリケーション(iOSまたはAndroid対応)は、集中ダッシュボード、重要な統計情報、インシデントの再割り当て、連絡先の統合、インシデントタイムラインなどのすべての機能を提供します。ユーザーごとのアクセス許可と細かいカスタムアクセス制御は、どのデバイスでも可能です。それはインシデント管理のワークフローをより合理化します。どこにいてもモバイルデバイスから迅速かつ簡単にインシデント管理ができるようにします。インシデント管理プロセスの中では絶対不可欠なものです。

※このコンテンツはwww.pagerduty.com/blog/の抄訳です。

モバイルでのインシデント管理

モバイルでのインシデント管理。 どんなときも。 どこでも。

すべてのデバイスで、卓越したユーザーエクスペリエンスを備えたインシデント管理ライフサイクルを実現します。 PagerDuty Mobileアプリケーションを使用すると、アラートを視覚化し、外出先でアラートを確認、解決、再割り当てすることができます。 モバイルアプリ、メール、SMS、電話などのマルチチャネル通信オプションを使用すると、アラートやインシデントの更新を見逃すことがありません。

“ iOSアプリが本当に好きです。 オフィス外にいる間にすべてのインシデントを認知し、エスカレートし、解決する能力は本当に素晴らしいです。 “

モバイルインシデント管理の詳細をご覧ください

			インシデントを作成する


			モバイルアプリから直接新しいインシデントを簡単に作成できます。


		
		
			モバイルアプリ


			iOSとAndroidの携帯電話、タブレット、スマートウォッチでインシデントを管理します。


		
		
			アラートと通知


			アラート音をカスタマイズして、無制限のプッシュ通知アラートを受信することができます。また、割り当てられたインシデントについて承認、エスカレート、解決されたことを知ることができます。


		
		
			インシデントの詳細


			インシデントの詳細、インシデント履歴、オンコールスケジュールを表示します。 オープンしているインシデントに対して、認識、解決、再割り当てすることができます。


		
		
			スケジューリング
			自分またはチームのオンコールスケジュールとブックされたオーバーライドを表示します。


		
		
			インシデントをスヌーズする


			すぐに解決する必要のないアラートをスヌーズします。

PagerDutyのインシデント解決プラットフォームは、ノイズを削減し、インシデントをより迅速に解決するのに役立ちます。