BLOG
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がどう役立つかに関係なく、失敗から学び、絶えず改善を続ける文化を吹き込み、顧客を幸せにし、楽しい時を過すことが本当に大切です。 あなた自身のゴールを達成するために働く毎日の中で、本当に大事なことを忘れないでください。