CALMS フレームワーク

課題や緊急事態でさえ、DevOps 文化をテストする絶好の機会となります。開発者、運用チーム、カスタマー アドボケートは、課題に対して一丸となってチームとして課題解決に当たっていますか? インシデントの事後分析は、責任のなすりつけ合いをするのではなく、次のインシデントの結果を改善することに重点を置いていますか? 答えが「はい」の場合は、組織が DevOps 文化を受け入れていることを示す良い兆候です。

大きく成功している企業ほど、すべての部門、そして組織図のすべてのレベルで DevOps 文化を導入しています。このような広い規模では、「DevOps」という用語は対象が狭すぎるので不要です。こうした企業はオープンな通信チャンネルを有しており、定期的な対話の機会を設けています。さらに、顧客を幸せにし続けることが、プロダクト マネジメントと開発チームの両方の責任であると認識しています。そして、DevOps は 1 つのチームだけの仕事ではなく、全員で行うものだということを理解しています。

自動化は反復的な手作業を排除し、反復可能なプロセスを生み出し、信頼性の高いシステムを作ります。

まだ自動化を実施していないチームでは通常、自動化の構築、テスト、デプロイ、プロビジョニングから始めることになります。開発者、テスター、運用担当者が協力する理由は、すべての人にメリットをもたらすシステムを構築する、ということだけで十分でしょう。

これまで自動化を行ったことのないチームは、継続的なデリバリーから始めましょう。これは、多くの場合はクラウドベースのインフラストラクチャを活用して、一連の自動テストによって各コードの変更を行い、自動化したデプロイによってビルドをパッケージ化して環境間でプロモートする手法です。

これを導入する理由は、人間よりもコンピューターの方がより厳密かつ忠実にテストを実行するからです。コンピューターによるテストでは、バグとセキュリティ上の不備をこれまでより早く検出できます。そして、デプロイの自動化によって環境間のドリフトを IT/ 運用に警告することで、リリース時に予想外のことが起きることを軽減します。

DevOps の大きなメリットして他にも「コードによる構成 (Configuration As Code)」があります。開発者は、信頼性が高く、メンテナンスもしやすいことから、モジュラー型で部品組み立て方式のアプリケーションを開発しようとしています。同じ考え方を、クラウドや企業の独自ネットワークでアプリケーションをホストするインフラストラクチャにも広げることができます。

DevOps の世界で起きている自動化は「コードによる構成」と「継続的デリバリー」だけではありませんが、開発チームと運用チームの壁を壊す存在であることから特にここで取り上げました。DevOps でデプロイを自動化して、共通のプロビジョニングが実施された環境に徹底的にテストされたコードを送信すれば、「自分のマシンでも問題なく動いた!」などという発言は意味のないものになります。

ソフトウェアの話題で「リーン」という言葉を聞くと、通常は価値の低い活動を廃止して効率を向上し、決然とアジャイルを実践することを思い浮かべます。DevOps をより適切に表すのは、継続的改善に努めて失敗を受け入れるというコンセプトであり、これが実験的なマインドセットの基礎となります。

DevOps のマインドセットは、あらゆる場所で継続的な改善の機会を認識することです。わかりやすい例としては、チームのプロセスを改善する定期的なふりかえりなどが挙げられます。わかりにくい例としては、製品の新規ユーザーに対する異なるオンボーディング アプローチの A/B テストなどが挙げられます。

アジャイル開発のおかげで継続的な改善は主流の考え方になりました。アジャイル手法を初期の段階で取り入れた人たちによって、完璧なプログラムを届けるために顧客を 6 か月待たせるより、シンプルなプロダクトを今すぐ顧客に届けることの方に価値があることが証明されました。プロダクトを継続的に改善していけば、顧客が離れていくこともなくなります。

この取り組みを行う場合、失敗を避けて通ることはできません。そのため、チームが失敗を受け止めてそこから立ち直り、学びを得ることができるようにしましょう (これを「打たれ強くなること」と言う人もいます)。ほとんど失敗することがないと、アトラシアンでは懸命に取り組んでいないと見なされます。

DevOps の観点から見ると、失敗は罰に値するような違反ではありません。物事はどこかの時点で失敗する運命にあることをチームで想定しているため、早期に失敗を見つけて短時間で修正できるような開発の進め方をしています。事後分析では、コードに問題をもたらしたチーム メンバーを突き止めることではなく、プロセスが失敗したポイントとそれを強化する方法に重点を置きましょう。どうしてでしょうか。それは、継続的な改善と失敗には密接な関係があるからです。

継続的な改善の取り組みが実際に効果を発揮しているかをデータなしで証明することは困難です。ありがたいことに、ユーザーがプロダクトに費やした時間、ブログ投稿が売り上げを生み出したかどうか、ログに重要なアラートが出現する頻度などのパフォーマンスを測定するツールとテクノロジーがたくさんあります。

あらゆることを測定できますが、だからといってすべてを測定する必要はなく、推奨もされていません。アジャイル開発を参考にして、まずは基本的なことから始めましょう。

開発からデプロイまでどれくらいかかりましたか。

同じバグや失敗はどれくらいの頻度で起こっていますか。

システム障害から復旧までどれくらいかかりますか。

現在自社製品を使っているユーザーはどれくらいいますか。

今週のユーザー数の増減はどれくらいですか。

しっかりとした基盤を整えることで、フィーチャーの使用状況、カスタマージャーニー、サービスレベルアグリーメント (SLA) に関して洗練された指標をより簡単に得ることができます。ロードマップの作成と、次の大きな動きに向けた仕様の策定を行うときに、こうした情報が活躍することになります。

このような充実したデータは、チームの意思決定をサポートするだけでなく、特に他の部門のチームと共有したときはさらに強力な威力を発揮します。たとえば、マーケティング チームは売り込みに利用できる魅力的な新機能を求めているとします。一方で、製品は技術的負債を多く抱えているため、大量の顧客離れが起きています。ロードマップを裏付けるユーザー データを提供することで (たとえ機能より修正プログラムに重心を置いたものでも)、合意形成と関係者との同意の取り付けを実現しやすくなります。

すべてのチームを高いパフォーマンスを発揮する DevOps チームに生まれ変わらせる魔法の杖があればよいのですが、実際のところ DevOps の変革にはさまざまなプラクティス、文化的な哲学、ツールが必要になります。しかし、これまでご紹介してきたとおり、開発と運用のサイロを取り壊すことには、信頼の向上、ソフトウェア リリースの迅速化、より信頼性の高いデプロイ、チームと顧客の間のフィードバック ループの改善など、大きなメリットがあります。

DevOps の導入は簡単ではありません。しかし、適切なマインドセット、取り組み、ツールがあれば、組織は大きなメリットをもたらす DevOps の変革を実現できます。

開発チームと運用チームの間に長年軋轢がある原因の大半は、共通の土台がないことです。責任を共有して成功を分かち合うことが、分断を埋めるのに大きく役立ちます。開発者は運用の最大の重荷である「障害時の呼び出し」をサポートすることで、すぐに信頼を勝ち取れます。DevOps では、アプリケーションの構築を行った人間がリリースと実行にも関与するというアイデアを重視しています。

このアイデアから「構築した者が運用する」というフレーズが生まれます。これに従うことによって、チーム全体で実践的なアプローチが促進されます。ただしこれは、開発者を雇って、優れた運用担当者として作業を兼務してもらうということではありません。アプリケーションのライフサイクル全体で、開発者と運用担当者が互いにタッグを組むということです。さらに、レポートによると、ピアレビューされたコードと製品は、より良いデリバリーとパフォーマンスをもたらす唯一のレビューであることが示されています。実際、外部レビュアーは、レビューをまったく行わないのと同じくらい効果的ではありませんでした。

多くの場合、DevOps を取り入れているチームでは、エンドユーザーが見つけた問題への対応を行いながらプロダクションの問題のトラブルシューティングも行う開発者の役割を持ち回りにしています。この役割では、顧客から報告があった緊急の問題への対応、必要時のパッチの作成、顧客から報告があった不具合のバックログの作業も行います。「サポート担当の開発者」はアプリケーションが実際にどのように使われているかについて多くのことを学ぶことになります。また、運用チームと深く関わることで、開発チームは信頼を勝ち取って互いに尊重し合うようになります。

アトラシアンは、大手ベンダーや Marketplace アプリとの統合によって、チームが愛用しているツールを利用して必要なツールチェーンを構築することを検討しているチーム向けに Open DevOps を作成しました。今すぐ試してみましょう。