OK、Google。次のオンコールはいつだっけ？
VoiceOpsは次に進む準備が出来ている？
想像してみよう ： PagerDutyからコールがあり、静かな声であなたに、注意すべき問題があるよと伝えてくれる。あなたの心中はきっと乱れ、心の声が次のように聞こえるだろう。
“げげ！これは直さなくっちゃ！”
“どうすればいい？”
“これは他人の問題かも”
…あるいはここには書けないような汚い言葉かも。
DevOpsの動きが立ち上がるということは実は、担当者は9時から5時まで個室に詰めて問題を解決するだけでは済まなくなるってことだ。 スマートフォン、ラップトップ、高速な家庭用Wi-Fiが使えるようになって、人々は自宅で仕事をすることも求められるようになった。 何かが起きれば、いつどこにいても、多数のプラットフォームを通じて通知を受け、対応できる。
でも今のテクノロジー・フォワード・ソーシャルや数多くのコミュニケーション・オプションがあるにもかかわらず、ラップトップや信頼できるWi-Fiにアクセスしないとか出来ないといったこともある。例えば通勤中や、コーヒーを飲んで会議をしているときとか、歯科医のオフィスで根管治療を受けているときとか。 こういうケースでは、声で反応するほうがより自然に感じる（根管治療中は除くけど）。
“エスカレーションしてよ。今私は答えられない。 “
“ああ分かった。確認。”
“うーん。担当者を増やすようリクエストして。データベースチームのEllenを探してくれるかい。 “
このシナリオを念頭に、われわれPagerDutyの中では、人々が実際にPagerDutyとどう話したがるかを研究し始めた。 まずPagerDutyと最も関連性の高い2つの状況を考えた。
戦闘中：多くの人々が大規模なインシデントに対応している状況で、複数のチームが絡んでいて、会議ブリッジで通信している可能性が最も高い。
小競り合い：1人の担当者が、マイナーなインシデントを確認して処理をしており、ダッシュボード、メトリック、およびランブックを参照して、一人で頑張っている。
しかしもう一つのシナリオがある：平時だ。これは、各チームが比較的静かな時間を最大限に活用してスケジュールを編集したり、分析結果を チェックしたり、サービスを設定したり、オーバーライドを管理する時間だ。 自宅の音声対応デバイスがあったら、みんなどう信頼を得るかを考えてみよう。 相互作用のほとんどは、比較的「平和」なものだ。消費者は、比較すれば緊急でないコマンドを試すことで、家庭の音声対応デバイスを信頼し始めている。
“今日は傘がいる？
“冗談を言ってみてよ”
“チーターってどのくらい速く走れるの？”
システムの状態をチェックすることは、天気をチェックするのと同じくらい自然でなければいけない。 平時のVoiceOpsは、人々がデジタルオペレーションを管理する方法を変えるはずだ。UXデザイナーのCorinna Sherman氏や、ソフトウェア技術者のZayna Shahzad氏は、平時のVoiceOpsの可能性を見出し、次にGoogle Assistant、Google Homeデバイス、そして PagerDuty APIを使ってプロトタイプを作った。
われわれはActions on Google開発者コミュニティとチームを組んで、先月共同でハックイベントを開催し、そのプロトタイプをPagerDutyコミュニティやHackbright AcademyとCode2040の出席者と共有した。
このイベントで我々は、Actions on Google AssistantとPagerDuty APIを使ってデモを作るためのブレーンストーミングを全員で実施しアイデアをひねり出した。優勝者はGoogle Homeデバイスを授与されたので、イベント後も引き続きプロジェクトに取り組める。さらに、Actions on GoogleのDevエバンジェリストであるIdo Greenが、参加者が音声を使った設計の原則を理解し、いくつかのコードラボをわたり歩き、Dialogflowでさまざまな自然言語技術を使って時間をかけて改善する方法を共有するのを支援した。
VUI Design from Ido GreenからのVUIデザイン （訳注：スライドが開きます）
学んだことは？
VoiceOpsは、 小競り合いの際のシナリオで、担当者が予定外のマイナーなインシデントの解決に独自に取り組んでいるときに、その役に立つ。
VoiceOpsは平時のマネージャーに約束しており、通常は毎日自分のチームのPagerDutyアプリケーションをチェックしない人にも答えを提供する。
VoiceOpsはまだ戦闘時に対しては準備が整っていない。Corinna氏が指摘しているように 、アクセントの認識の問題があったり、音響に問題がある部屋では、音声認識はかなりひどくなる。
音声認識と対話がうまくいけば、人々はVoiceOpsを使ってうまく働けるだろう。音声対話が設計どおりに動作しない場合、人々は不満を感じ、信頼しなくなる。
もっと学びたい？それなら プロトタイプをチェックし、コミュニティフォーラムでディスカッションに参加してください。 あなたはオンコール中に何を尋ねる？オンコール中でないときは？ 私たちはそれを聞きたい。 また、PagerDutyコミュニティに参加してイベントなどの最新情報を忘れずに入手してください。
本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
DevOps
DevOpsの失敗から学ぶ方法
DevOpsの失敗は微妙な話題です。それが一般的にはDevOpsは障害を回避する方法として認識されているからです。その結果、DevOpsの実践に失敗した場合、状況はほとんど絶望的に見えます。しかし、フェイルファーストのビジネスアプローチや、「失敗して早く修正する」アジャイルの手法がしばしば証明するように、DevOpsの失敗は実は正しい方向への一歩なのです。失敗から学び、DevOpsの実践を、後まわしではなく早く、より大きな成功に導く道に向かわせるための第一歩です。
DevOpsはアジャイルに発するものです。頻繁なフィードバックループで開発サイクルを短くすると、顧客のニーズに一層合致した製品の提供に集中できます。フィードバックループの活用ポイントは、顧客からのフィードバックを通じて行動から学び、何が正しいのか、何が改善できるのかを測定することです。
フィードバックループは、頻繁な変更と失敗からリスクを実際に減らすよう学べる機会を提供するため、効果的です。DevOpsの実践に打撃を与える失敗はいろいろなので、それにどう対応するかが重要です。ではいくつかを細かく見てみましょう。
インシデント対応の失敗
ソフトウェア関連の問題が発生した場合（ソフトの展開に関連することであろうとバグであろうと）、それが起きたという事実よりも、どう反応したかがたいていは重要になります。 ここでの失敗は、以下を含む複数の形で発生する可能性があります。
過剰反応**：障害からの回復や、失敗の繰り返しを避けるために、過度の時間を費やしたり、過度に多くのリソースを費やしたりすることです。
誤った反応**：情報の欠如による問題の誤診や、問題の見積もりを誤ること。
無反応**：問題を早急に修正したり、効果的に修正したりするのを忘れ、直後に問題が再発すること。
インシデント管理とKPIによる成功を評価することは、DevOpsの成功の要件である測定の重要な部分です。関連する情報を浮上させ、他のチームメンバーを募集し、個々のコンポーネント（およびそれらの背後にある人）を原因として示すのではなく、全体としてシステムを見て、インシデントを迅速に評価して解決します。
ここでの取り組みには、インシデント対応、知識の伝播、将来の問題を回避するための過去のインシデントからの学習、問題解決の自動化による迅速な対応といったことが含まれます。
プロセスの作り過ぎ
DevOpsは単なるプロセスまたはツールであると考えて、厳格で正式な一連の手順を設定することをに走る人もいます。しかし、あまりにも多くのプロセスを作ったり、プロセスについて厳格すぎたり、特定のツールセットを強制すると、組織の柔軟性が失われる可能性があります。 そうではなく、DevOpsには、組織の敏捷さを向上させるツールと手順が含まれている必要があります。
例えば、ソフトウェア開発と展開の効率の全体を測定するツールは、その効率を向上させるためのフィードバックを提供するのに役立ちます。 どうやって？ 変更が必要な箇所と削除する必要のあるボトルネックを指摘するのです。厳格になりすぎると、変化するユーザーベースまたは市場のニーズを改善または満たすために迅速に変えられなくなる場合があります。
DevOpsの範囲を制限する
DevOpsの実践の仕事は、組織内の一人の人間やチームだけには任せられません。 私は、既存のソフトウェア展開とメンテナンスの問題をすべて修正するためにある人が”DevOps Person”として特別に雇われ、”DevOps stuff”を魔法のように行う状況を目撃しました。しかし、そこには足りない点がありました、「そのアプローチが失敗する」と考えなかったことです。
同様に、顧客サービスおよびサポート担当者が、事前に知らされていなかった、週末にインストールされた新機能に関してコールを受けた状況も見てきました。 主なサポート担当者がお客様からソフトウェアの変更を知らされるような場合は、DevOpsの失敗が起きます。
DevOpsは、アジャイル開発から学んだことを取り入れ、ソフトウェアの展開全体を通じてエンドツーエンドで適用する、構成的な実践方法です。 これはビジネス全体の他の機能にも拡張する必要があります。 つまり、開発作業は各プロジェクトではなく顧客への価値に沿って行われ、製品チームはITスタッフとだけではなく、コールに対応する人や、技術文書を作成する人、アプリケーションを宣伝して販売する人、ビジネススポンサーとして働く人たちとも共に働かなくてはなりません。その中には将来計画を立案するエグゼクティブも含まれます。 フィードバックループを拡大して組織の全員を構成するには、誰もが覚えておくべきことがあります。
ここでは、フィードバックループ、コミュニケーション、および主要な測定活動を組織のすべての部分に拡大することを含みます。 また、サードパーティベンダー、サプライヤー、コンポーネントを除外しないでください。 外部コンポーネントの検証、監査、および監視も含めてください。
不毛な責任追及と競争を回避する
アジャイルは、組織のソフトウェア配信パイプラインでのボトルネックを明らかにすることが多く、物事を遅らせていると思われる人や活動を指摘するのは簡単です。これが起きると、DevOpsは意図していたのとは正反対に、チーム間をばらばらに引き裂くくさびを打ち込むことになってしまいます。
そうではなく、サイロ（真空中で仕事をしようとするチームや人）を取り除き、ボトルネックや改善を特定するよりも先にチーム間の壁を壊してください。 全員が最初に協力して責任を共有することで、チーム同士が競争する結果ではなく、１つにまとまるという改善ができます。
サイロを徹底的に排除する
組織内で例外を作っていることは珍しいことではありません。 たとえAgileやDevOpsで実際に成功を収めている組織でもあることです。おそらく、それはレガシーなアプリケーションや、過去に実績があるチーム、またはベテランの従業員です。 しかし、DevOpsの実践から個人やチームを除外するのは面倒な作業です。
サイロは、組織のソフトウェア展開の実践を複雑化して毒になる可能性があります。 そのサイロに共同創業者が含まれていたとしても、組織のDevOpsが奨励するプロセスとコラボレーションから免除されるべきではありません。 一言で言えば、DevOpsはサイロとボトルネックを取り除くことを意味します。例外なしに。
開発環境を無視する DevOpsは、本番環境と展開するもの以外にも適用されます。 アジャイル開発のスプリントが成功し、本番環境の導入が自動化され、テストが継続的に行われている場合でも、開発環境にこれらの実践を拡張しないと、独自の問題が発生します。たとえば、開発環境とテスト環境が同じツール、アプローチを使っておらず、その運用環境を管理する担当者によって管理されてもいない場合、ソフトウェアが想定外のユニークな構成に初めて遭遇したときに生産上の問題が発生します。
チームからのアクセスをむやみに増やさない DevOpsの結果としてチームワークが強化されるのは良いことです。またソフトウェアの開発過程で、新しい手順やコンポーネントにさらされるにつれ、チームメンバーが成長する能力も向上します。 しかし、これに伴う責任の追加分担を忘れると、重大な失敗につながる可能性があります。 たとえば、DevOpsはUI開発者がアプリケーションのデータベースに慣れるのに役立つかもしれませんが、UI開発者がDBの変更を自分で公開する権限を持つようになると、誤って本番データベースを変更するといった事態も起こるかもしれません。 ボトルネックは除去すするにしても、大災害を避けるためにコントロールも必要です。
重要なプロダクションシステムへの予期しないアクセスを監視して報告し、意図しない変更をロールバックする（またはロールフォワードする）手順を導入するべきです。
結論：つまりは人の問題です
ゴールはDevOps自体の成功ではありません。プロセスでも活動でもありません。ゴールはソフトウェアとカスタマーエクスペリエンスと組織を改善するためにDevOpsの使命をまっとうすることです。 これらのいずれかが欠落している場合は、DevOpsで成功していると思っても生きるのは難しくなるかもしれません。
これまで説明したことすべてに現実の人々を巻き込むよう肝に命じること、それが重要です。 DevOpsがどう役立つかに関係なく、失敗から学び、絶えず改善を続ける文化を吹き込み、顧客を幸せにし、楽しい時を過すことが本当に大切です。 あなた自身のゴールを達成するために働く毎日の中で、本当に大事なことを忘れないでください。
DevOps
デジタルオペレーションを人間的に
午前3時、あなたは暖かく居心地良い布団の中で、枕に垂らしたよだれに気づかぬまま、深い夢の中で癒されています。
ところが突然、あなたは目が覚め、心臓が高鳴ります。電話が最大音量で鳴っています。隣で寝ていたパートナーは目を開けて寝返りを打ち枕を頭にぶつけ、眠りに戻る前にあなたを睨みつけます。あなたは電話を黙らすために手を伸ばし、アラートの発生を知ります――夜間のバッチジョブがまたトラブったようです。 あなたは一言怨嗟の声を上げ、ノートパソコンの前に座って2時間の仕事に就きます。気が付けば夜明け。あなたは睡眠不足で疲れていますが、数時間後にはオフィスにいなければなりません。
いつものことですか？
微妙なワークライフバランス
今日の常時稼働の世界では、これがオンコール担当者の日常です。健全なITエコシステムを維持するのは、昼夜を問わず準備ができていることを要求する厳しい仕事です。最近のPagerDutyの報告書「グローバルITワークライフバランスの現状」によれば、ITエンジニア800人を調査したところ、51.3％は週に10回以上、仕事や生活が中断されたと答えています。 IT運用は担当者の健康を犠牲にしながらインフラとアプリケーションの健全性に重点を置いてきました。オンコール対応者は勤務時間中と時間外に関わらず、週末にもアラートを受信し、疲れ、欲求不満が高まり、睡眠不足に陥っています。担当者だけがストレスを感じているわけではありません。その家族も同様に影響を受けています。
これは広範な問題です。調査の回答者の94％が、アラートが家庭生活に影響を与えると答えました。ほぼ同数の回答者（94.5％）は、アラートによる中断が仕事の生産性に悪影響を及ぼしていると回答し、72％は彼らの上司は担当者が抱えている問題をほとんど知らないと答えています。
これは憂慮すべき数字です。これらのストレス要因がタイムリーに対処されない場合、従業員は燃え尽き、仕事と生活のバランスを求めて退社してしまうでしょう。私たちの調査によると、回答者の23.1％が現在の会社のワークライフバランスが悪い場合、新しい仕事を探すだろうということが分かりました。熟練した担当者を新たに雇うためのコストは30万ドル以上にのぼるため、スキルの高い従業員を維持することは会社の利益のために重要です。
チームを健全に保つための洞察を得る
PagerDutyはオンコール担当者が直面する課題を認識し、企業がIT運用とオンコール担当者の健康を全体的に改善するのを支援するため、データ分析とアドバイザリー・コンサルティングを組み合わせたPagerDutyオペレーションヘルスマネジメント（OHM）サービスを開始しました。 OHMサービスは、PagerDutyの幅広い分析機能のポートフォリオの一環として、企業に最も価値のある資産、つまり人材について、実践的な洞察と助言を提供します。私たちはIT運用を人間的にし、その背後にいる人々の生活の改善に導きます。
各企業はオペレーションヘルススコアと呼ばれるスコアを使い、我々が特許出願中のアルゴリズムと機械学習、ドメインの専門知識とピアベンチマークデータを活用し、業務の健全性を定量化することができます。OHMサービスを通じて、企業は組織やプロセスの改善点を把握し、オンコール担当者とチーム、サービスの健全性を損なう問題を特定して修正することができるようになります。
チームの健康、生産性、そして幸せを向上させたいとお望みならば、今すぐ無料のオペレーション健康度アセスメントをご覧ください。
本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。
DevOps
HybridOpsとは？
CentralOpsとDevOpsの融合であるHybridOpsがエンタープライズの世界で盛り上がっています。昔から大企業には、 重大インシデント対応の中心的役割を果たすオペレーションセンター（サービスオペレーションセンター、テクニカルオペレーションセンター、ネットワークオペレーションセンター。略称SOC、TOC、 NOC ）がありました。
これは長年にわたり実行可能なアプローチでしたが、DevOpsにより従来のCentralOpsモードのオペレーションが、開発と運用の両方のスキルを持つ開発者の新しい波と相反し始めました。さらに、CentralOpsとDevOpsを融合する必要があることを認識する企業が増えてきており、デジタルトランスフォーメーションを成功させるための仕組みを整えることがますます重要になっています。
協調戦略の重要性
HybridOpsに移行する際の課題の1つは、IT運用における最も重要な資産＝人のインパクトを評価することです。
最近まで、IT Operations（ITOps）の監視対象は、常にサーバやアプリケーション、サービスに集中してきました。欠落していたのは、ITOpsのアラートが及ぼすオンコール担当者とその家族に対する影響を評価する能力でした。
たとえば、新しいサービスのデプロイや既存サービスのアップデートのために、オンコール担当者が夜間に何度も起こされた場合、担当者の欠員やバーンアウトのリスクが高くなります。現在、企業はデジタルトランスフォーメーション（HybridOpsへの移行など）を成功させるために必要とするリソースのわずか19％しか持っていないことを考慮すると、従業員の減少は大きな問題です。
さらに、うまく調整された移行戦略がなければ、サイロ化の可能性は非常に高まります。たとえば、NOC、SOC、TOCの集中管理に不満を感じているDevOpsチームは、 AWS EC2とDatadogを導入し、インフラストラクチャの管理と監視を独自にすることができます 。しかし、このアプローチの欠点は、いくつかの点で明らかです。
企業環境では、そのチームがサポートしているインフラストラクチャの問題が非常に目立つようになります。
大規模なインシデントが発生した場合、 経営幹部チームなどのビジネス関係者は、通常、復旧に関する最新情報をNOCに問い合わせます。上記のようなサイロ化した組織では、インフラストラクチャはNOCには見えず、NOCは関連するアップデートを提供できないため、解決までの時間が遅くなる可能性があります。
HybridOpsをうまく実装し、サイロ化を排除し、NOCチームとDevOpsチームの間で負荷を分担する合理的なシステムを採用する組織と比べてみましょう。このシナリオでは、NOCはアラートを適切なDevOpsチームにルーティングし、チームは得意とするインシデントの処理ができます。NOCは、インシデントが複数のチームにまたがってカスケード接続されているかどうかを把握し、ビジネス関係者への情報を更新し、DevOpsチームはインシデントの修復にエネルギーを集中することができます。 結果として、アラート、インシデント、インシデント解決の流れが劇的に改善されます。
オペレーションヘルスマネージメントサービス
いかなるITOpsオペレーションモデルも、それを選択して実装するのは、特に企業環境においては恐ろしく複雑なことです。問題の深さを理解し、必要な機能を開発したベンダーが提供するツールと監視ソリューションを利用しなければ、デジタルトランスフォーメーションのリスクははるかに大きくなります。
PagerDutyのオペレーションヘルスマネージメントサービスは、ITOpsの人々の健康と福利に関する監視を提供する業界初のサービスです。ビジネスリーダーとテクニカルリーダーは、人々の健康を重視した運用インフラストラクチャと改善のための具体的な推奨事項を深く理解しています。このサービスを使用して、これらの推奨事項を実装した企業は真のHybridOpsを達成することにより、従業員の幸福度、定着率が高まり、デジタルサービスのスムーズな提供が可能になります。
本記事は米国PagerDuty社のサイトで公開されているインテグレーションガイドをそのまま日本語に翻訳したものです。日本語環境での動作を保証するわけではありません。原文はこちらを参照してください。
DevOps
デジタルオペレーションの人間的側面
2017年2月28日の朝のこと、インターネットが広大な範囲で利用できなくなりました。 Slack 、Quora 、GitHub、Trelloなど、数千人が頼りにしている個々のサイトからサービスに至るまでたくさんのものが利用できなくなりました。たぶん、人為的ミスがインターネットの大部分をダウンさせたこの日を覚えているでしょう。AWSの幅広いコンポーネントが機能しなくなりました。一つの停止でインターネットが無秩序になったのは今回が初めてではありませんが、AWSの規模を考えれば、その影響はいつでもありうると感じられます。
多くの場合、危機の最中に重大な事件に対処する人間の側面を忘れることがあります。例えば人々に連絡する難しさや、個人的な連絡先情報を見つけること、複数のタイムゾーンに主要なスタッフが分散していること、会議から人を引き離すことなど、予期しない出来事のため計画していた作業を中断することなどです。
PagerDutyは、こういう時代に存在する最先端のデジタル運用管理プラットフォームです。私たちは、チームや組織が事態が悪化したときにPagerDutyを使いインシデントを先取りして管理することを支援し、チームがやりたい仕事に集中できるようにします。当社の製品は、予期せぬ事態が発生した場合の行動のプラットフォームとして機能します。私たちは主にエンジニアリングとITチームにフォーカスしてきましたが、チームや人をサポートする他のビジネス分野にとってPagerDutyがどんな意味を持っているかも考えていました。
過去には、エンタープライズシステムや人事部門こそが、AWS停止などの事態が発生したときに必要となる重要な人員の詳細を把握するシステムの責任者でした。人事チームはまた、大事な顧客への影響が発生したときに情報を提供する必要があります。私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合に、私たちが仕事をするために必要な重要な情報もそこにあります。私たちが日常的に利用している人気のあるサービス、社内のメッセージングとVoIPサービスは、すべて利用できなくなる可能性が隠れています。これらのクラウドサービスの大規模な停止またはダウンタイムの間、顧客と従業員に情報を提供し、行動と対応を調整することは困難です。
「 私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合、私たちが仕事をするために必要な重要な情報もそこにあります。」
現代の企業には、通常、人の情報をすべて記録したシステムがいくつもありますが、その詳細を最新の状態に保つインセンティブを人々に持たせていることはめったにありません。 PagerDutyのようなインシデントや危機対応の鍵を握るシステムでは、従業員全員が緊密な接触を維持する気にさせる深いインセンティブと日常のビジネスニーズがあります。そのプラットホームを活用して正確な人の情報を得、応答を調整すればスムースになります。
これは、ビジネス全体で高度に採用されているプラットフォームをHRチームが使用する絶好の機会であり、私たちを行動の心臓部につなぎとめ、妨げにならないように支援します。私たちが最も避けたいことは、素早い返事と行動を求められている最中に、社内で不要な騒音や官僚的な行動を作り出すことです。
従業員に対する環境的、物理的、またはデジタル的な脅威など、人事部門が責任を持つべき危機のことを考えてください。私たちに必要なのは、状況を管理し、重要な情報にアクセスし、サイロになったりワークフローにまぎれずに、あるいは、チケットによって遅くならずに応対できるようにすることです。いつもそうとは見えないかもしれませんが、HR部門は、さまざまな状況になると、しばしば第一級の対応ができる部門です。ベストプラクティスとアジャイルワークフローを使い重大な事態に対処するには、法律、設備、ベンダー、サイバーセキュリティチームと連絡する必要があります。
当社の顧客の多くは、物理的な在庫やサプライチェーンを持たないビジネスモデルを採用しています。デジタルインフラストラクチャがビジネスの主体であり、顧客の経験に大きな影響を与えます。エンジニアリングから法律およびマーケティングに至るまで、インフラストラクチャと顧客体験の成功に投資しています。リアルタイムの顧客への影響がある場合、そのインフラストラクチャ全体を調整できるプラットフォームを使う方が優れた対応ができます。
“ これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。”
テクノロジーに焦点を絞ったビジネスでは、エンジニアリングチームや開発チームが使用するプラットフォームやプロセスから学ぶ必要があります。これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。各チームが醸成した文化、つまり最前線に至るまでのカスタマーエクスペリエンスの説明責任を果たせること、チームが対策を組織できると信頼すること、非常に高い協調性から学んだこと、そしてDevOpsチーム、ITチーム、顧客が習熟してきたインシデント対応へのアプローチから、恩恵を受けることができます。ビジネス全体がこれから学ぶことができます。
“ HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。”
さまざまな機能が共有プラットフォーム上で共同して働ける新しい方法を見つけ出すことは私をワクワクさせます。例えばデータを集めることと機械学習を活用して、あるパターンが出現する前にそれを見つけたり、過去の反省から対策を覚えたり改善したりすることができます。 HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。私たちは社員が顧客のために構築した経験を彼らから借用していますし、オンコールエンジニアの人生をより良くしていくことで、デジタルビジネスに関わる全員の人生をより良くすることができるはずです。
DevOps
DevOpsトランスフォーメーションに血を通わせる
チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。
「これがDevOpsと何の関係があるの？」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。
では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか？
PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。
避けられない変化を認識する
今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。
しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。
あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。
DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。
ビジョンへの賛同を得る
トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。
小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。
アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。 この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。
開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。
インセンティブの変化を理解する
PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか？
従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。
DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。
オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。
DevOpsを自分のものにする
チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。
DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。
このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。
指標を理解する
DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。
新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか？ デプロイの頻度は？ バグのトラブルシューティングにはどのくらいの時間がかかるか？ 四半期ごとのダウンタイムはどのくらいか？
これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。
理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間（MTTA）と解決する平均時間（MTTR）に注目しますが、重要な指標はこれだけではありません。
これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。
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チームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。
DevOps監視は複数のツールの組み合わせで
監視ツールはDevOps チームの人生を楽にします。正しいDevOps 監視ツールを選択することで、効率的なワークフローとエンドユーザーの幸せを手に入れることができます。
多様なDevOps監視ツール
ほとんどの開発チームのための通常の監視ツールキットには、次のものが含まれます（ただしこれに限定されません）。
インフラ監視ツール アプリケーション・パフォーマンス・モニタリング（APM）ツール ログ解析ツール
各レイヤーに目を通し、あなたのDevOps監視プロセスにどこにフィットするか見てみましょう。
インフラストラクチャとネットワークの監視
これらのツールは、サーバ、ルータ、スイッチなどのインフラストラクチャとネットワーク全体を監視できます。インフラストラクチャ監視ツールは、重要なビジネスプロセスに影響を与える前に、ITインフラストラクチャの問題を特定し解決するのに役立ちます。また、古いシステムで障害が発生する前に、アップグレードの計画を立てるのに役立ちます。インフラストラクチャとネットワークの監視ツールは、メンテナンスの停止がユーザーに与える影響を最小限に抑えます。
インフラストラクチャの健全性を監視することで、インフラストラクチャ上で実行されているアプリケーションの正常性を把握できます。ただし、これらのツールはアプリケーションを完全な一連のサービスとして監視しません。その意味で、今日のクラウドアプリケーションには適していない従来の監視方法を採用しています。
例：Nagios、Zabbix
アプリケーションパフォーマンスの監視
アプリケーション・パフォーマンス・モニタリングツールは、その名前が示すように、アプリケーションのパフォーマンスを監視します。アプリケーションの動作を可視化し、ユーザーに影響を与える問題を検出し、それらの問題を迅速に解決するのに役立ちます。エンドツーエンドのアプリケーションフローを監視し、コードレベルの詳細を含むトレースを提供します。APMツールの診断には深い洞察が含まれており、パフォーマンスの低下や障害の原因となる可能性のある正確なコード行を見つけられます。
APMツールはパフォーマンスの向上、処理速度低下とダウンタイムの防止に役立ちますが、APMだけでは解決できない、さらに深いトラブルシューティングが必要な問題もあります。これらの問題には、ログファイルのインデックス付けと検索が必要です。残念ながら、APMツールはログファイルを分析せず、セキュリティ攻撃を検出できません。この種の分析には、ログ解析ツールが必要です。
例：AppDynamics、New Relic、
ログ解析
ログ解析ツールは、ログファイルを格納しインデックス付けするスケーラブルで信頼性の高い方法を提供します。ファイルをすばやく検索し、ログデータに基づいて詳細な分析を作成し、セキュリティ違反やサイバー攻撃を監視することができます。ただし、エンドツーエンドのアプリケーションパフォーマンス監視は提供されず、コードレベルのトレースを明らかにすることもできません 例：Splunk、Elastic Stack
これらのツールは、エンドツーエンドの監視のためのものではありません。インシデントが発生したときにこれらのツールのいずれか1つだけを使うと、解決の鍵となる部分が欠けることがあります。
監視ツールにはさらにその監視が必要
監視のためにこれらのツールを全て採用したとしても、インシデントが発生したときに混乱を招く可能性があります。これらツール全てからの警告は、重複するデータをたくさん提供します。これにより、あなたはツール間を行き来してあちこち見回することになり、チームだけでなく顧客にも多くの不満を引き起こす原因になります。ツールセット全体からのデータのオーバーロードに直面するので、MTTRは長くなります。インシデント管理での監視を簡素化が必要なのです。
監視ツールを集約する単一のインシデント管理プラットフォームが必要
ITチームやDevOpsチームは、互いに深く統合されたベスト・オブ・ブリード（複数ベンダーの組み合わせ）のツールを使用した監視を長年受け入れてきました。これらの全ての監視ツールを使用すると、矛盾する情報と膨大なアラートが表示されることがあります。その全てを管理し、問題の概要を把握するためのセンターハブが必要です。PagerDutyのようなインシデント管理プラットフォームは、インシデントが発生した際の混乱から秩序を回復するために不可欠です。
インシデント管理ツールは、優先度の低いアラートを抑制し、適切な人に適切なタイミングで優先度の高いアラートを表示することで、ノイズからシグナルを引き出します。インシデント管理ツールは、その他の監視システムと深く統合されているため、あらゆるDevOpsチームが必要とする真のエンドツーエンドの監視が可能です。十分に錬られた通知オプションを使用すると、PagerDutyなどのインシデント管理ソリューションはチームに自分たちへの通知方法を選択させることができます。さらに、これらのプロセスを自動化することで、解決までのの時間を大幅に節約し、全体的なMTTRを削減できます。
全ての監視ツールにはそれぞれ独自の機能が用意されていますが、全体を管理していないと混乱が生じます。1つで全てをカバーできるDevOps監視ツールはありませんが、1カ所から全ての監視ツールを管理して、送られてくるデータをフィルタできるPagerDutyのようなソリューションを使えば、完璧に一歩近づくことができるでしょう。
DevOps：開発者の視点から
「オペレーションルームに歩いて行く – もうこれ以上何もする必要はないと思う」
開発者のための最新の機能のリリース（訳注：英語サイトに飛びます）で、PagerDutyのシニアエンジニアDavid Yang氏と私は、私たちの内部アーキテクチャが単一のモノリシックなコードベースから数十のマイクロサービスの組み合わせにまで進化していくのを見てきました。
彼は、8000人以上のPagerDutyの全顧客にアラート通知を送信するサービスを所管するIncident Management – Peopleチームのテクニカルリーダーです。私たちは座って、彼らのサービスの運用について彼のチームがオーナーになるよう切り替えた後の生活について話しました。 私たちが見た利点と欠点に関するいくつかの観察を紹介します。
今はチームがサービスのオーナーになっています
開発者がサービスのオーナーになるモデルに移行して以来、開発者の独立性はますます高まっています。副作用は、インフラストラクチャのプロビジョニングと管理の難しさを最小限に抑えられたことです。現在、チームは邪魔と障害を最小化するように最適化したいと考えています。 インフラをサポートするチームは、人間の介入の必要性を最小限に抑えるために優れたセルフサービスツールを提供することに重点を置いています。
開発者がコードのオーナーになると、サイクルタイム、つまり「これは問題だ」というメッセージがどこかで表示されてから実際に問題を解決するまでの時間が短縮されます。これは非常に価値があります。
文化面での変化は
人々がより多くのコードのオーナーになり、自分たちが運営するシステムのために一般的にはより多くの責任を負うようになると、道を邪魔するものを排除することを重視する文化が広がります。各チームは、 「自分が今まで、あるいは将来ブロックされていないことを確認するにはどうするか」という考え方に向かって最適化されます。ブロックされるともっとはっきり分かります。以前は、ホストをプロビジョニングするたびに私は毎回運用チームに問い合わせなければなりませんでした。 私のチームは他のチームの障害物で隠されていないため、自分たちの障害物をよりはっきり見ることができます。
私たちには、エンドツーエンドの顧客価値を提供するプロセスのすべてを所有することに重点を置いたチームがあります。これは非常に貴重です。
インシデント対応プロセスではどうに役立つ?
サービスのオーナーシップの境界が明確になっています。運用の問題が発生した場合に、影響を受けるチームを簡単に特定できます。そして、自分が従うべき正しい手順、例えばそれは「これがそのチェックリストです」という客観的な手順ですが、それを知っているということが大事です。 これによって問題の解決に100％集中し、インシデント前後のコミュニケーションに集中することができます。
それほどうまくいかなかったことも
サービスのオーナーになっていても、そのサービスに問題が発生しないとは限りません。当社のサービスの運用維持に専念するためには、そのためだけに使う時間が必要です。 これが結局はチームの時間の多くを占めます。特に知識のギャップがあるレガシーサービスで問題になります。 当初は、私たちのスプリントでの作業性を守るために十分なガードレールを設置していませんでした。 これは客観的な意思決定を可能にするためにKPI（特定のスケーリング目標や運用負荷レベルなど）を活用することで改善されています。
将来は?
[業務関連のワークロードと機能開発ワークのバランスをとるため]各チームは、メトリックによって客観的な意思決定を推進するために、次のように問い続けています。「私はこうした道具を日常的にどう活用していますか？ どのようにして客観的な意思決定を行うのですか？」と。
組織内の業務の中で変更を実行しようとすると、多くのコラボレーションが必要になります。 適切なメトリックが何であるかを把握し、それらのメトリックについて議論することも必要です。
DevOpsへのよりディープな監視の導入
継続的インテグレーションのポイント は、ビルドとテスト を自動化し、効率と品質を開発パイプラインにもたらすことです。しかし、継続的インテグレーションプロセスに伴って頻繁な更新が行われると、状況が悪化してしまうことがあります。
重大なインシデントや何か悪いことが起こるとパニックになります。それがインシデント管理のよくある風景です。しかし、何かが起きた後に常にそうなるでしょうか。初めからインシデント管理を継続的インテグレーションプロセスに組み込むことで、アカウンタビリティ、可視性、透明性を全く新しいレベルに引き上げることができます。
ここでは、いかにしてDevOpsへの深い監視を行い、それがアプリケーション開発方法を変革するかについて説明します。
コードの品質に対する責任は 継続的インテグレーションフェーズから始まります
DevOpsの目標は、開発チームと運用チームの協力を促進し、お互いのニーズを理解し、状況が悪化したときでも相手の責任を追求するのではなく共に解決することです。稼働時間の向上は必ずしもOpsチームだけの役割ではありません。DevOpsでは、新たに加わった開発者でさえ稼働時間に責任を感じ、ダウン時には協働することができるはずです。
継続的インテグレーションを実装する大きなメリットのひとつは、開発チームと品質管理チームの両方が出荷品質のコードに対して責任を負うことです。新しいビルドがコミットされるたびに、一連の自動ユニットテストによってコードが検証されます。インシデント管理がこのレベルで実装されていれば、何か不具合が発生した場合には適切なデータが手元に残るため問題を効果的に解決できます。こうして、誰も責めずに、パニックに陥ることもなく迅速にトラブルシューティングを行うことができます。インシデント管理を導入すれば高い品質を求める文化が醸成され、開発チームと品質管理チームは互いに可用性に責任を負うようになります。
緊急医療チームと同じように、責任者が現場に到着する前に最初に働く初心者のエンジニア、つまりオンコールエンジニアを待機させることも良いでしょう。この責任の文化を醸成するには、監視データをチーム間で見えるようにするモニタリングとオンコール管理システムが必要であり、公平なシフトに基づいて計画外の作業を分担する必要があります。
開発チームと運用チーム間の可視性
チーム全体の取り組みと進行状況を把握することで、誰もが自分の仕事に集中できるようになります。多くの企業は、悪い事が起こったときやインシデントが発生したときにのみ、Opsチームに新しいコードの実装を任せます。結果として、Opsチームは不信のために変更を控えていると非難され、更新が遅くなります。
Devチームが計画段階から変更点についてOpsチームに情報公開を行っている場合、それがビジネス全体にどのように役立つかを理解することができます。Opsチームに開発フェーズから新しいアイデア、今後の機能、考えられるリスクを認識してもらうことは、チーム全体の意識を高めます。Opsチームは何かあってもいいようにいつも準備ができているため、安心していられます。
早い段階でインシデント管理を実装することで、アプリケーションの健全性と問題が発生したときに何をすべきかを誰もが理解できるようになります。誰もが大きな図式を知っており、より迅速にトラブルシューティングを行うことができます。
透明性には統一された指標が必要
チーム全体が、危機の間お互いの責任を認識しているほど、彼らはより効果的に動き、より速く正常に戻すことができます。
複数のソースからデータを収集し、相関させ、分析することにより、DevとOpsは継続的な洞察を得ることができます。しかし、そのデータは実用的になった場合にのみ価値があります。インシデント管理ソリューションを使用すると、適切な人に問題の全体像を提供し、最終的にはアプリを壊してしまう可能性のある問題をゼロにすることさえできます。
最後に、インシデント管理ツールが問題が起きている時にリアルタイム通知を提供することで、実際に役立つことを確認してください。さまざまな重大度の問題の経路を決めるプロセスを定義することは非常に重要です。データを捨てようとは思いませんが、手元の問題を解決することに貢献しない無意味なメトリックを通知されることは望みません。
DevOpsへのトランスフォーメーションに成功するためには、継続的インテグレーションとインシデント管理が不可欠です。チーム全体にとってたのもしいリリーフとなり、ダウンタイムに対するより迅速な対応が可能になります。インシデント管理によってDevOpsエンジンは故障することなくスムーズに回転するようになります。
フォースの覚醒：PagerDuty + DatadogでDevSecOps
セキュリティ専門家として長年過ごしてきた私は、Datadogのような企業が、変化するセキュリティ環境にどう対応しているかに常に関心を持っています。 昔はセキュリティ組織がセキュリティの責任を完全に負っていて、ビジネスの周縁（perimeter）を保護することに重点を置いていた、ということも思い出せます。しかし、クラウド、モバイル、Webアプリケーションの出現で、周縁は消えてしまいました。 それと並行して各企業は、セキュリティとは開発チームと運用チームの中で共に責任を担い 、統合されるべきだと認識するようになっています。
それに向き合いましょう：Webアプリケーションに対する攻撃はMenace(脅威。ファントム・メナースから)となっており、毎年急速にデータ侵害が増加しています。 Rogueアクターは、インフラ、ソフトウェア、およびプロセスの弱点を悪用しています。私たちはこれに対してどのようにしてStrikes Backしますか？ New Hopeをここに…DevSecOps！
お分かりでしょうが、私は子どものころからスターウォーズの熱狂的なファンです。いつもこの話題のシリーズの新作が発表されるたびにワクワクしています。最新版は私にこの、遠く遠く離れた銀河の（原文はa galaxy far, far away ）の教訓がDevSecOpsに関して私に教えてくれたことを思い出させました。
“覚えたことは全て忘れるのじゃ” – ヨーダ
賢明なJedi Masterが言ったこの言葉を言い換えると、あなたがずっと真実だと思っていた知識のいくつかは、いつか偽に変わることもある、と言っていたはずです。DevSecOpsについて言えば、それはトランスフォームの成功を邪魔することもあります。時代遅れのツールとプロセスを使うことで、セキュリティチームが物事を停滞させる可能性があるのです。セキュリティは、組織内のセキュリティのマインドセットを変える一部として調整が必要であり、より新しいツールやプロセスがどれだけ良きパートナーになるかを知っておく必要があります。クラウドアプリケーションの監視サービスであるDatadogは、ツールとプロセスを更新する必要があると認識した企業の1つです。 そのセキュリティチームは開発部隊から学び、PagerDutyをアラートとレスポンスに使用し始めました。 PagerDuty Securityチームの一員として私は、ビジネスに自前のサービスを生かすこと（Eat Your Own Dog Food）も 自分のプラットフォームをセキュリティ業務の一環として使うこともできます。 しかし、なぜでしょうか？
“こいつはケッセルまで12パーセクで飛べた船だ！”- ハン・ソロ
PagerDutyでは、私たちは即応性と応答性を備えたモデルを志向しています。 例えば、セキュリティイベントが発生していたりリソースが準拠していないことをどれぐらい早く発見できるでしょうか？あるいは起きた問題を収めるためにどうに迅速に対応できるでしょうか？ といったことです。DevSecOps一部は、セキュリティについてスピード面でスケールする自動化された決定をすることです。 ミレニアム・ファルコンが光速で飛ぶほどは速くないかもしれませんが、迅速に対応できることは、潜在的なコスト削減とリスクの削減につながります。 スピードが要（かなめ）なんです！
すべてのリリースが100％安全で、100％稼働率を達成していると言えればよいのですが、現実にはありえません。現実では問題が起こり、どのくらい迅速に対応できるかが収益に影響します。 2017 Ponemon Cost of Data Breach Study は、インシデントレスポンスチームを組織することで、レコードあたり最高19ドル分の損失を削減できることを示しました。 適切な人にアラートして迅速に関与させることが重要です。
PagerDutyでは、クラウド内でマルチテナントのSaaS（software-as-a-service）プラットフォームを運用し、さまざまなツールを使用してインフラストラクチャを監視および保護しています。 これらのツールは、私たちが採掘してフィルタリングできる多くのシグナルを生み、PagerDutyプラットフォームとのインテグレーションにより、関連するセキュリティイベントとアラートをまとめることができます。 これにより、イベントに即応して、 インシデント対応プロセスを開始し、迅速に対処と復旧ができるようになります。
これはセキュリティインシデントに限りません。 開発者がコードを所有している環境では、クラウドインフラ内のリソースがコンプライアンスから逸脱したり、セキュリティリスクが発生したりする事態を迅速に判断することもできます。 迅速に対応して開発者と協力して問題を修正し、最善のセキュリティプラクティスについての早急なフィードバックを提供し、以後のプロセスを改善することができます。
“やるか、やらないかじゃ。試しはない ” – ヨーダ
DevSecOpsのアプローチを実装するのは、難しい作業のように思えるかもしれません。また成功するためには、組織内のセキュリティの考え方を変えるなど、多くの課題があります。 それ自体は、ジェダイの精神的なトリックを使うべきだと思えるかもしれません。しかし、あなたはプロセスにコミットし、その後に自分の間違いから学び、また過去に同じことをした他の人から学ぶ必要があります。DevOpsと同様に、DevSecOpsは反復学習と改善のプロセスでなければなりません。 DevSecOpsは、迅速なフィードバックを提供するためにセキュリティプロセスを自動化するための適切なツールを選択することでもあります。PagerDutyを活用すれば、そのトランスフォーメーションを助けられると思います。
あなたの組織でDevSecOpsをうまく実装する方法の詳細を知りたいですか？ Datadogの導入事例をチェックしてください。
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。
ChatOps:チャットボットがインシデントを引き受けます
あなたの考えていることをずっと追いかけていて、あなたの計画の実行を助ける、そんな小さな ロボット があったら素晴らしいでしょう。もし、あなたがインシデント監視インフラストラクチャを担当する管理者なら、それは存在します。チャットボットと呼ばれる彼らは、インシデント管理ワークフローを最適化するための鍵です。
ここではチャットボットとChatOpsを使うのが、DevOps手法を採用している組織にとってとても重要な理由について説明します。
チャットボットの定義
「チャットボット」は人によって異なるものを意味します。大まかに定義すると、チャットボットは、人間と「会話」をするプログラムです。チャットボットはずいぶん昔から存在しています。あなたがAOL（注：America Online）がまだインターネットを支配していた時代に育ったなら、例えばSmarterChildというAIMインスタントメッセージングサービスのためのチャットボットを覚えているでしょう。
インシデント管理とインフラストラクチャの監視の分野でいうチャットボットは、もっと狭い意味を持ちます。彼らは人間の言うことを理解し会話をするだけでなく、人の代わりにアラートを監視しインシデントに対応します。
言い換えれば、この意味でのチャットボットは、SlackやHipChatなどのコミュニケーションプラットフォームと統合され、人間の入力に応答してコマンドを処理するプログラムです。コマンド自体は、多くの場合、バックグラウンドで動作するサーバで実行されていますが、管理者が行う必要があるのは、何をするかチャットボットを教えることだけで、残りは事前に定義された手順に基づいて自動的に処理されます。
チャットボットとChatOps
チャットボットは開発業務におけるツール、プラットフォームであり、ChatOpsと呼ばれます。彼らは開発者と運用チームに以下のような利益をもたらします。
コマンドを実行するための便利なインタフェースを提供する
すでにSlack、HipChatや他のコミュニケーションプラットフォームをすでに使っている場合、なぜコマンドを実行するために異なるインタフェースに乗り換えるのでしょうか。チャットボットならばあなたがコマンドを実行する必要はありません。チャットインターフェイスから直接実行させることができるので、ずっと素早く実行できます。
チーム全体を可視化
あなたがチャットボットとの対話を公開していれば、参加するすべての人があなたが実行したコマンドを確認することができます。これは、あなたのチーム全体を可視化し、チームメンバーが同じコマンドや矛盾したコマンドを実行していないことを確認できます。そして同時に、チーム全体が学習する機会も提供します。
リアルタイムなアクションを促進
伝統的に、チームは集まり、計画を立て、別れて、実行します。チャットボットとChatOpsを使うと、コミュニケーションと操作インターフェースが統合されているので、対話と実行が同時に可能です。重要なオペレーションを実行する前、計画を立てるための時間が要らないとは言いませんが、例えばインフラの障害に対応しているときのように時間が最重要である場合、計画とオペレーションが同時に行えるのは大きな利点です。
チャットボットとChatOps、DevOpsチーム
これらの利点は、ほぼすべてのタイプの組織に有用です。組織がDevOpsチームスタイルのワークフローに移行しつつある現在、これは特に重要だといえるでしょう。
それはなぜか。DevOpsチームの2つの原則は、シームレスなコミュニケーションとオペレーションの俊敏性であるためです。ソフトウェアの継続的デリバリー（と透明性と公開性）を求める場合は、チームメンバー間のコミュニケーションギャップを回避する必要があります。また、インシデント対応時に継続的デリバリーのパイプラインを壊さぬよう、迅速かつ容易に行動できる必要があります。
同じ論理は、監視とインシデント管理にも適用されます。監視チームを継続的に活動できるようにしたい場合、リアルタイムでインシデントを特定し解決するため、瞬時に可視化されたコミュニケーションが可能な手段が必要です。素早いアクションと効率的かつ協調的な方法でチームメンバー間に責任を持たせるための方法です。チャットボットはこのすべてを可能にします。そのため、チャットロボットはDevOpsの世界を席捲しているのです。
DevOpsのROIを測定する方法
DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか？ どうやって投資を価値あるものにしますか？
DevOpsがROIに与える影響
DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。
あなたのチームはあなたの最大の資産です
DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。
ROIをビジネスの目標に結び付ける
では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか？ これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。
時は金なり
鍵は効率化
柔軟に最適化を
チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。
ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。
どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。
そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。
「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」（ウィリアム・ブルース・キャメロン）
ビジネスへの教訓
DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか？」という問いになってきています。
ROIの決定に使用できるDevOps指標
これらをあなたのビジネス目標に当てはめてください
指標
詳細とメリット
1日／週／月あたりの本番環境へのプッシュ数
本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。
1か月／年あたりのダウンタイムの分数
自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します
自動テストカバレッジ
自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。
新入社員がコードを本番環境にデプロイするのに必要な時間
新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。
新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間
手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。
従業員の幸せ
作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS（Net Promoter Score）を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。
- PagerDuty 9月の製品アップデート情報
- PagerDuty最高製品開発責任者による「AIと自動化が実現するオペレーショナル・エクセレンス」講演録画が公開
- PagerDuty、新しいアップデートで運用効率を向上
- PagerDuty 8月の製品アップデート情報
- Juneteenthを受け入れる：インクルージョンへの旅
- Custom Fields on Incidentsのユースケーストップ５
- ゼロトラストセキュリティーの正体と、気にしておくべき理由
- 5 年間の社会的影響: 公約 1% に対する進捗状況を振り返る (そしてこれから)
- AIOpsと自動：Forresterの主席アナリストであるCarlos Casanova氏をゲストスピーカーとして迎えた対談
- Runbook Automation for Incident Resolutionの新製品トライアルを活用する
