Blog
ブログ

2018年7月27日  (更新日:2022年3月11日)

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

Logate by Sematext はエンタープライズクラスのログ管理ソリューションです。 Logseneは、Fluentd、Logstash、Syslogなどの幅広いログ収集ツールからログを受信でき、Java、Scala、Go、Node.js、Ruby、Pythonなどのプログラミング言語用の多くのロギングフレームワークをサポートしています。 また、LogseneはElasticsearchのAPIを使いKibanaと連携し、アラートや異常の検出機能を内蔵しています。クラウド(SaaS)とオンプレミスの両方で利用可能です。また、 SPM Performance Monitoringと統合して、メトリック、イベント、ログを相関させます

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年4月20日  (更新日:2022年3月11日)

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

LogicMonitorはSaaSベースのパフォーマンス監視ソリューションで、IT Opsチームがインフラストラクチャ、アプリケーション、およびサービスをうまく監視できるようにします。 LogicMonitorの監視機能とPagerDutyの高度なオンコールスケジューリング機能およびアラート機能を組み合わせることで、インフラストラクチャ内に問題が発生したらすぐに通知を受けることができるようになります。

詳しくはこちら

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

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

Logglyは世界で最も一般的なクラウドベースのログ管理サービスです。インフラストラクチャ全体のログを集計し、検索し、問題の根本原因を特定し、全体傾向の監視を行う単一のインターフェイスを提供します。Logglyで発生したアラートをPagerDutyに送信すると、PagerDutyはSMS、電話、Eメール、またはプッシュ通信を介して適切な技術者にアラートします。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年4月18日  (更新日:2022年3月11日)

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

Logentriesは、開発からデプロイ、そして継続的な管理とサポートまでのあらゆる段階で実用的なインサイトを提供するログ管理、分析プラットフォームです。API経由とeメール経由でPagerDutyにアラートを送ることができます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年8月8日  (更新日:2022年3月11日)

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

LogDNA は、ログを監視し、ライブログを表示し、問題を可能な限り早期に特定するのに役立つ、異常検出ツールです。

詳しくはこちら

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

災いの後で:過去のインシデント経験から学ぶ方法

インシデント 管理の主な目的は、インフラストラクチャ に影響を与える問題を特定し解決することですが、インシデント管理業務はそこで停止するべきではありません。

お客様のチケットに反応するだけではなく、アラートシステムが生成する豊富なデータを活用すれば、問題を事前に検出しインフラストラクチャをより弾力的に運用するための洞察を得られます。

ここでは、データの収集と分析の方法、情報を扱う際に探すべき点など、過去のインシデント管理データを扱うための戦略の概要を説明します。

データの保存と標準化

過去のインシデント管理データを分析するための第一歩は、情報を収集して解析する標準化された方法を見つけることです。しかしながら、Screen-Shot-2017-12-14-at-11履歴ログの量と形式がさまざまな監視システムによって大きく異なるため、困難な場合があります。

いくつかの監視システムは、事後に調べることができる記録をまったく残しません。たとえば、Pingdomはリアルタイムモニタリングのための優れたツールですが、昨日のことではなく、今起きていることを伝えるように設計されているので、独自の履歴データをあまり提供しません。

他の監視システムは、限られた期間だけデータを保管したり、扱いにくい形式で保管したりします。たとえば、Snortのデータを分析するにはパケットダンプを調べなければならない場合があります。金曜の夜にWiresharkにハマるのが好きでない限り、やっかいな仕事です。

さらに、多くの監視システムを設置している場合は、違う場所にバラバラにデータをダンプする可能性があります。いくつかのツールはローカルマシン上の/var/logにログを書き出します。ローカルマシンのログは見逃しやすく、メンテナンススクリプトで削除されることもあります。あるいは、一定ではない期間ログをクラウドに保存したりします。これは、すべての履歴データを一度に分析するには理想的とは言えません。

これらの理由から、インシデント管理データを最大限に活用するには、次の2つのことを確実に行う必要があります。

アラートとログを中央の収集ポイントに送信します。モニタリングシステムや ローカルストレージがそれをサポートしていれば、必要に応じてアラートやログを保存できます。 収集ポイントのデータを標準フォーマットに変換し実用的な洞察を抽出します。

これにはLogstash、Splunk、Papertrailなどのツールが役立ちます。 これらは、サイロ化された場所からデータを収集し、中央のストレージポイントに転送できます。

PagerDutyは以上のソースや他のソースからデータをインポートし、標準化されたフォーマットに変換してパターンや傾向を可視化し、データの集中化と相互関連付けを行い、根本的な原因などを特定することができます。

データの表示と分析

データを表示する最も簡単な方法は、Webベースのインターフェースを使用する方法です。ログから特定のイベントを検索したり、インシデントの現在のステータスを監視したりするために使用できる洗練された検索機能が求められます。

Webインターフェースは、小さな傾向の発見、特定タイプのインシデント履歴のトレースから、全体状況の理解まで可能にしてくれます。アラートの表やリストは、システム全体の傾向を理解するのに役立ちません。 PagerDutyがレポートに含めるようなインシデント管理データに基づく可視化は大規模な情報の解釈に役立ちます。

特にプログラムでデータを分析する場合は、必要に応じてログデータをエクスポートできるAPIが重要です。 PagerDutyのAPIを使用すると、必要な形式でログデータを簡単に収集しエクスポートできます(Events API v2では、そのデータをすべて共通の形式に自動的に正規化します)。

何を探すか

データ分析をしたら、次に何を探すべきでしょうか。 監視しているインフラストラクチャのタイプによって異なりますが、一般的に注意すべき点は次のとおりです。

インシデントが発生している頻度。この数が時間の経過とともに変化する場合は、その理由を知りたいでしょう 平均認識時間(MTTA)と平均解決時間(MTTR)。これらの時間を把握することで、チームがインシデント管理をどの程度効果的に処理しているかを知ることができます。 チームの誰が最も多くのアラートを処理しているか。これはメンバーの評価基準になるだけでなく、アラートが適切に配分されているかどうか、そして最適な人に届けられているかどうかの判断基準になります。たとえば、1人の管理者が応分の分担以上のアラートを受け取っているときは調整する必要があります どの監視システムが最も多くのアラートを生成しているか。上記のように、さまざまな監視システムからのアラートを1つのログ記録場所に統合すれば、最も多くの情報を提供しているシステムを特定することができます。システムのパフォーマンスが低下しているかどうか、またはノイズが多すぎるかどうかを確認し、必要に応じてしきい値を調整できます。

これらのヒントに従えば、悲惨な歴史を繰り返すことはありません。

それがインシデント管理がいかに実を結ぶかです。 インシデント対応は治療行為ですが、過去のインシデント管理データを含むフィードバックループを継続的に作成すれば、インシデントの予防も可能になります。

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

DevOpsの失敗から学ぶ方法

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

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

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

インシデント対応の失敗

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

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

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

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

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

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

プロセスの作り過ぎ

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

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

DevOpsの範囲を制限する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

カスタマーサポートチームがインシデント管理をどのように活用できるか

「インシデント管理」と聞くと、ITプロフェッショナルがバックエンドシステムを管理していると考えるかもしれません。おそらくカスタマーサポートチームは自分たちとは関係ないと考えていることでしょう。

ですが実際のところ、カスタマーサポートチームもインシデント管理から多くの利益を得ることができるのです。

顧客を幸せにする

ほとんどすべてのIT専門職は、カスタマーサポートに回ってくるようなことがらは一般的に良くないことだと考えているでしょう。私たちは顧客に技術サポートに頼るような経験をさせたくはありません。カスタマーサポートを提供することに直接的なコストが伴うだけでなく、こういった経験をした顧客は将来的に顧客でなくなる可能性が高まるからです。

結論は、顧客を満足させることが重要であるということです。満足した顧客は、あなたの会社との経験を何人かの友人に伝えてくれるかもしれません。怒っている顧客は、自分のTwitterフォロワーに体験をシェアしたり、中には消費者庁に駆け込むようなこともあるかもしれません。

では、カスタマーサポートとインシデント管理はどんな関係があるでしょうか。その性質上、カスタマーサポートは受け身の機能です。通常、顧客は問題に突き当たるとテクニカルサポートに電話を掛け、テクニカルサポート部門は顧客の苦情に対応することになります。インシデント管理も同様に受け身なものですが、予防的な対応も可能です。適切な監視ソリューションを使用することで小さな問題を解決して、チームをより大きな問題の解決に向かわせることができます。これにより、サポートコールが少なくなり、顧客満足度の向上にダイレクトにつながります。

積極的なインシデント管理を通じてサポートコールを削減するという考えは魅力的ですが、インシデント管理計画が適切に実装されている場合にのみ有効です。重大ではなかったり重複している警告は抑止し、より緊急な問題のアラートを発信することで、ソフトウェアはIT担当者の大きな助けになります。しかし、最終的には、インシデント管理プログラムの成功は、問題が発生したときに決定的な行動をとるITスタッフの能力に左右されます。

担当者を呼び出せることの重要性

インシデントが迅速に解決されるようにするためのひとつの方法は、発生する可能性のある問題をITスタッフが常に処理できることを確認することです。組織に24時間対応のITスタッフがいない場合は、呼び出し可能なサポートチームを持つ必要があります。これは全員が常にオンコールでなければならないというわけではありません。輪番制のコール対応スケジュールを組めば、ITチームの誰かが常に起こりうる様々なインシデントに対応可能になります。

時間外の緊急事態に対処するためにコール対応スタッフを用意しておくという考えは新しいものではありません。熟練のIT技術者であれば、たいていは週末や非常識な時間に呼び出された経験が一度や二度はあると思います。

ほとんどのITサービスは時間外の問題に対処するために誰かを呼び出すことを躊躇しないものですが、関係するすべての人がより無理なく日常生活を送れるようにするためには、いくつかのポイントがあります。

オンコールオペレーションのベストプラクティス

まず、時間外のインシデントでITスタッフにアラートを出すのは、インシデント管理ソフトウェアによって起動される自動プロセスでなければなりません。自動アラートを使用することで、IT担当者は問題を可能な限り迅速に認識することができます。自動プロセスをとっていないと、誰かがインシデントを発見してIT部門に電話をかけてくるまで、ITスタッフはその問題を認識できない可能性があります。その頃には、顧客の側でも問題を経験し始めているかもしれません。

これは別のポイントをもたらします。よほど小さな組織でない限り、1人のオンコール担当ではなく、オンコールチームを用意するのが一般的です。ITは複雑な分野であり、チームの誰もが組織全体で使用されているあらゆるテクノロジーの専門家であることを期待するのは非現実的です。オンコールチームを組織しておくことで、インシデントが発生した場合、問題を解決するために相互補完的なスキルセットを持つ人々のグループを確保することができます。これは、オンコール技術者が何らかの問題が発生したときに、解決に必要なスキルを持つ特定の人を探すより好ましい方法です。輪番制のコールスケジュールは、ある人に常に役割を負わせるのではなく、いつでも問題に対処できるチームが存在することを保証します。

業務時間外に待機するのは決して楽しいことではありませんが、24時間体制で顧客にサービスを提供する企業では、ITの専門知識を年中利用できるようにすることが非常に重要です。顧客は企業の最も貴重な資産であり、企業のブランドは顧客に依存しています。インシデント管理ソリューションを活用する積極的なカスタマーサポートチームは、問題が顧客に悪影響を与えるのを防ぐことができ、より高い顧客満足度につながります。

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

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

Kayakoは、お客様のビジネスに合わせてカスタマイズ可能なカスタマーサービスソフトウェアです。Kayakoでサポートチケットが作成・更新されるとPagerDutyで通知を受け取れます。また、オプションの電子メール解析ルールを設定すると、KayakoのチケットがクローズされたときにPagerDutyインシデントも解決できるようになります。このガイドはKayyakoバージョン4以前をお使いの方向けです。

詳しくはこちら

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

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

Kayakoは、お客様のビジネスに合わせてカスタマイズ可能なカスタマーサービスソフトウェアです。Kayakoでサポートチケットが作成・更新されるとPagerDutyで通知を受け取れます。また、オプションの電子メール解析ルールを設定すると、KayakoのチケットがクローズされたときにPagerDutyインシデントも解決できるようになります。このガイドはKayyakoバージョン5以降をお使いの方向けです。

詳しくはこちら

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

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

Server Densityは、Linux、FreeBSD、Windows、およびMacOS Xを実行するシステムに包括的なホストレベルの監視機能を提供する監視サービスです。Server Densityは、Apache、MySQLなどの一般的なサーバーソフトウェアも監視できます。 Server Densityは、PagerDutyにすべてのアラートを渡すように簡単に設定できます。 PagerDutyを使用すると、Server Density通知を受信でき、 アラートの自動エスカレーションを設定できます。 携帯電話からのアラートをエスカレートでき、オンデマンドスケジューリングも設定できます。

詳しくはこちら

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

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

Sensuは、サーバー、サービス、アプリケーションの健全性とビジネスKPIのためのオープンソースの監視フレームワークです。 Sensuは、AWS EC2インスタンスなどのクラウド内のシステムを監視するために設計されたものです。このガイドでは、Sensu CoreとPagerDutyを統合するプロセスについて説明します。なおこのガイドの手順はSensuの無料版であるSensu Core用です。 Sensuのエンタープライズ版にはPagerDutyとの統合機能が組み込まれています。

詳しくはこちら

2018年2月28日  (更新日:2022年3月11日)    |    ベストプラクティス

セキュリティインシデント対応者としての生活

小さな目でスパイして

「誰がリンクをクリックしたかを追跡する機能を構築したい」

そのメールをセールスチームに送ったとき、私は気味の悪いストーカーと思われたようだ。なぜクリックされた地球上のすべてのリンクを追跡したいのだろうか? 私は私についての厄介な噂を払拭するために、どんな状況だったのか知る必要があると判断した。そして、セールスチームのメンバーが警戒してセキュリティチームに報告したため、実際にフィッシング攻撃という脅威が検出された。

私の考えを説明するフォローアップメッセージを書いたとき、私はカーテンを剥がして「セキュリティのしくみ」を明らかにすれば会社全体が利益を得ることができると気づいた。拡大と混乱の期は熟した。セキュリティインシデント対応者のニーズを理解すれば、PagerDutyを使用して顧客が新しい問題を解決する助けになれると。

セキュリティインシデント対応の仕組み

セキュリティチームには、ビジネスに対するサイバーセキュリティリスクを軽減し、顧客の信頼を向上させるという2つの主な目的がある。私たちが毎日直面している本当のリスクは、攻撃者がいつでも任意のコンピュータ上でマルウェアを実行できることだ。セキュリティインシデント対応チームは、私たちが直面している脅威の影響を理解し軽減するプロセスを経験している。ここでPagerDutyで行う高度な手順は、 NISTのサイバーセキュリティフレームワークに基づいており、以下のようなセキュリティインシデント対応計画からなっている。

検出

封じ込め

対応

回復

さて、PagerDutyセキュリティチームがこのような脅威にどのように対応しているかを見てみよう。

急ぎの質問としては、

悪質なマルウェアが含まれているか?

悪質なマルウェアはどこででも発現したか?

この2つの質問に答えることで、攻撃の最初の影響を理解し、被害を封じ込めることができる。

最初の質問への答えは、同僚からの攻撃のレポートを受け取ったときにすぐに分かった。私たちの手元にはリンクが付いた電子メールがあり、リンク先がマルウェアかどうかを確認することができた。そのような場合、安全のため隔離されたコンピュータの中の仮想マシンを使用してリンクをたどって疑わしいファイルを検査する。こうすれば、リンクが何か悪質なものをダウンロードした場合は、直ちに仮想マシンを止めることができるため、マルウェアは損害を与えられない。

この方法を使用すると、リンクがマルウェアをインストールしたことが検出された場合、そのリンクをブロックして、オフィスネットワーク上の誰もそれをダウンロードできないようにできる。しかし、ブロックを設置する前に誰かがすでにダウンロードしていたらどうだろうか?

これは2番目の質問につながる。悪質なマルウェアはどこででも発現したか? この質問に答えるには、誰かがマルウェアをダウンロードしたかどうかを調べる必要がある。誰がリンクをクリックしたのか? マルウェアをダウンロードした人が複数いる場合は、すぐにネットワークからコンピュータを切り離して、マルウェアが他のシステムと通信できないようにする必要がある。マルウェアはネットワーク上の他のコンピュータを攻撃し、コンピュータからデータを盗み、インターネット経由で攻撃者に送信する可能性がある。これらの行動は、それぞれ「lateral movement」(横への動き)と「exfiltration」(抽出)と呼ばれる。

感染したコンピュータをネットワークから切り離した後、マルウェアが実行可能だったかどうかを確認する。必ず、問題に対応する前に、まず攻撃をカットすること。できるだけ早く感染が広がらないようにする。ひょっとするとあなたは幸運かもしれない。マルウェアはWindowsやMacでのみ実行可能で、それ以外のOSにダウンロードしても実行されないならば、あなたが影響を受けることはない。

では次に、3人のユーザーがリンクをクリックし、悪意のあるソフトウェアが彼らのコンピュータで実行できることが判明したシナリオを見てみよう。これは本当に危険な状況だ。3台のコンピュータがネットワークから切断される前に、マルウェアが実行中に何をしたのか理解する必要がある。インターネット越しにデータを抽出したのだろうか? 横への動きを使って別のコンピュータを攻撃することができたのだろうか? パスワードを盗もうとキーロガーをインストールしたのだろうか? これらの質問に対する答えは、私たちがどのように対応し、攻撃から回復するために何をすべきかを決定する。

残念ながら、現在のところ誰かがリンクをクリックしてマルウェアをダウンロードしたかどうかを即座に特定できる技術はない。私はいつも誰もクリックしていないことを願っているが、それが望めなくともせめてどのシステムも影響を受けていなければ、夜はよく眠れるだろう――だから私は誰がリンクをクリックしたかを追跡したいのだ。

セキュリティのためのPagerDuty

インシデント対応チームがセキュリティイベントが検出されたときに迅速に対応することがいかに重要であるかをご理解いただけただろうか。リスクを減らすことが私たちが仕事をして給料を稼ぐ理由だ。あなたのためにできる私の挑戦は、以下の質問に答えること――セキュリティインシデント対応者は、PagerDutyを使用して対応にかかる時間をどのように短縮できるか? 彼らは横への動きを介して広がる前に感染を封じ込めることができた場合、どのくらいのリスクを排除することができるのか? どのくらいのコストを節約できるのか?

セキュリティのためにPagerDutyを! 以下のセキュリティに関するリソースを確認しよう。

セキュリティの混乱:SecOpsとインシデント管理によるITセキュリティの改革

セキュ開発者:PagerDutyを安全に保つ

シグナルサイエンスはセキュリティ上の異常に素早く対処し、PagerDutyで顧客データを安全に保つ

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

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

次世代インシデント管理:スクリプト化されたインフラストラクチャ

Chef、Puppet、Ansibleのような構成管理ツールの大きな利点は、データセンターを「スクリプト化された」インフラストラクチャに変えることです。人生の時間を無駄にするサーバのプロビジョニングや設定を手動で行う代わりに、構成ツールで自動化することができます。

ただし、これらのツールはインシデント管理を自動化するようには設計されていません。他のIT業務がスクリプト化されているときにインシデント管理だけを手動で処理する理由はありません。インシデント管理もスクリプト化されたルーに統合すべきです。インシデント管理のためのスクリプト化されたインフラストラクチャアプローチを採用することで、監視とアラート管理だけでなく、残りの操作も拡張できます。

問題

まず、インシデント管理に対するスクリプト化されたインフラストラクチャアプローチが非常に重要である理由について説明します。

まだ手動でインシデント管理、自分を責めないでください。あなたは悪い管理者ではなく状況の犠牲者です。最近まで自動化されたインシデント管理ソリューションは、Chefのようなインフラストラクチャ管理ツールを容易に利用できませんでした。

インシデント管理の要件も、今日のように常に複雑ではありませんでした。10年前のデータセンターには、たいていの場合、数十台のオンプレミスサーバがあり、手動でインシデント管理を処理できました。

しかし今日、インフラストラクチャは、拡張性と迅速な製品革新の要求から、ますます複雑なものになっています。オンプレミスのベアメタルサーバがあり、ローカル仮想サーバがあります。クラウドサーバ、コンテナ、モバイルデバイスもあります。IoT革命が本格化した今、まもなく冷蔵庫と電子レンジとパーキングメーターを追加する必要があるかもしれません。

これらすべてのデバイスでインシデント管理を効果的に実行したい場合は、可能な限り反復的な手作業を排除する必要があります。これを実現するには、急増するデータセンターインフラストラクチャの構成を自動化するのと同じ方法で、自動化およびスクリプト化が可能な次世代インシデント管理ソリューションが必要です。

ソリューション

スクリプト化されたインフラストラクチャの時代にインシデント管理を効果的に処理するためには、

適切な人にアラートを自動的にルーティングする。適切な人に問題を通知するのに手作業が入れば、プロセスは壊れてしまいます。

インシデントを自動的にエスカレーションします。ここでもまた、人々が行動を取ることを忘れ、特に巨大なインフラストラクチャを持っている場合は、人間が手作業で問題を再割り当てするのを待つことはできません。ChefとPuppetがサーバーを自動的に構成するのに十分なほどスマートなのと同じように、あなたのソフトウェアはあなたのために十分にスマートである必要があります。

スケーラブルにアラートの動作を管理します。インフラストラクチャスクリプトツール便利な理由の1つは、既存のリソースを最も効率使用することに優れているからです。彼らは、クラウド内のどこに仮想サーバを配置すべきかを知っています。同じように、インシデント管理ツールは、アラートを適切なサービスやチームに自動的にグループ化し、無駄なアラートは抑制してルーティングすることができるため、ノイズが減り応答時間が短縮されます。

ChatOpsと統合することで、インシデント管理作業から通信プロセスを切り離すことなく、チームがインシデント対応に協力できるようになります。さらに、チャットボックスを通じて、ChatOpsは特定のレスポンスタスクを自動化するのに役立ちます。

すべての監視ニーズをサポートします。AWS Cloudwatch、Nagios、Pingdomなど、複数の監視ツールを利用している可能性があります。インシデント管理をスケーラブルかつ自動化するために、これらのツールは手動による介入なしで連携する必要があります。すべてのソースからのアラートを自動処理するインシデント管理戦略で、あるアラートだけを除外するのは、他のすべてのインフラストラクチャをPuppetで構成しながら1つだけ手動でプロビジョニングするのと同様に問題があります。イベントを自動化されたワークフローに変えることができるソリューションで、すべてのツールを集中管理することが重要です。

100%の稼働。私はオンプレミスの通知だけに頼ることが悪い考えであることを思い出すために、この点を常に念頭に置いています。私はNagiosを愛していました。しかし、今日、アラートを届けるためにローカルで稼働するNagiosのようなツールだけに頼っていると、インフラストラクチャに問題があった場合、インシデント管理システム自体がダウンするリスクがあります。Nagiosを使用するのは良いことですが、残りの監視システムからのアラートを、インフラストラクチャの問題の影響を受けない集中型のクラウドベースのインシデント管理ソリューションに供給する必要があります。

レガシーなアラートと監視システムだけで作業していた場合、上の要求リストはファンタジーのように見えるかもしれませんが、そうではありません。スクリプティングされたインフラストラクチャがデータセンターを自動化するのと同じくらい効果的に、すべてのイベントに対して迅速なレスポンスワークフローを自動化するインシデント管理ソフトウェアがここにあります。あなたの仕事をはるかに生産的で効果的なものにするために、今はそれを活用する時です。

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

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

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

Scoutはいわゆるエンタープライズクラスのニーズに合わせて開発されたサーバ監視サービスです。リアルタイムグラフを使用してインフラを可視化し、ワンクリックで使える拡張性の高いプラグインと、カスタムソリューション用のAPIを提供します。

詳しくはこちら

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

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

Scalyrは、複数の機能を1つのツールに統合します:ログの集約、検索、分析、 ダッシュボードとアラート、外部モニタリングなどがあります。 PagerDutyのオンコールスケジューリングとアラート機能を組み合わせることで、システムが監視されていることを確認したり、問題が発生したときにオンコールチームに通知したりすることがより簡単にできます。

詳しくはこちら

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

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

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

SaltStackは、構成管理からサーバー自動化、監視サービスまで、幅広い機能とリモート実行を組み合わせた先進のシステム管理フレームワークです。 このドキュメントでは、SaltStackのリモート実行および構成管理ツールをPagerDutyとともに使えるように構成する方法について、詳しく説明します。

詳しくはこちら

<  123456789101112  >