DevOpsとは、開発と運用が密接に連携する開発手法を指します。ハイパフォーマンスなDevOpsチームを目指してDevOpsを実践するためには、行動の結果を計測し、次の行動に反映することが重要です。
DevOpsがうまくいかない、あるいはこれから始めたいという組織にとって何が必要なのか、考えてみましょう。ここでは、DevOpsの現状と実践する際のポイントのほか、DevOpsで陥りやすい課題への解決策について解説します。
企業におけるDevOpsの現状
そもそもDevOpsとは、「開発（Development）」と「運用（Operations）」を組み合わせたDevelopment and Operationsの略語です。
開発と運用が密接に連携し、システム設計から開発、更新までのサイクルを、短期間で柔軟かつスピーディーに繰り返す手法で、開発・運用の両チームの協調によって「優れたサービスをユーザーに安定的に提供する」ことを目的としています。
DevOpsを取り入れ、実践している企業は増えつつあります。とはいえ、DevOpsは比較的最近になって注目され始めた概念のため、社内のIT基盤の構築から始めている段階や、DevOpsをどう進めればいいのか、手探りで模索している段階の企業が多いのが現状です。また、DevOpsを始めたいけれど、どう始めたらいいのかわからないという企業もあります。ここからは、DevOpsを効果的に実践するポイントについて説明します。
DevOpsを実践するポイント
ポイント1：パフォーマンスをさらに高めるには測定が大切
DevOpsの原則的な要素としてよく登場するのが、「CALMS」という言葉です。これは、「Culture（文化）」「Automation（自動化）」「Lean（無駄がない）」「Measurement（測定）」「Sharing（共有）」の5つを指します。この中でも、チームのパフォーマンスをさらに高めるために肝要なのが、Measurement、つまり測定です。
開発の進捗スピードとチームの自主性を優先することが多く、測定は後回しにされがちなのが現状ですが、個々のメンバーの動きや作業プロセス、技術的なパフォーマンスなど、あらゆる事象を正しく測定し数値化しなければ、適切な管理はできません。また、開発プロセスに潜むウィークポイントを見つけて、改善することもできないのです。
チームの活動とその結果を漏れなく測定しておくことは、非常に大切です。このことは、DevOpsを実践する上で、最初に理解しておく必要があるでしょう。
ポイント2：SLOとリリース期間短縮のバランスをとる
DevOpsの考え方のもとで、開発工程を小さいサイクルで繰り返すアジャイル開発を進めていくと、どうしてもリリース期間の短縮ばかりが優先されがちです。しかし、品質や信頼性が伴わなければリリースのスピードを早めても意味がありません。サービスレベルの目標値であるSLO（Service Level Objective）とリリース期間短縮のバランスをとることを意識する必要があります。
ここで重要になるのが、DevOpsの考え方を実現する方法論ともいわれるSRE（Site Reliability Engineering：サイト信頼性エンジニアリング）です。SREには、開発・運用、そのほかのITチームと密接に連携しながら、業務を数値化して管理するという特徴があります。
これからDevOpsを実践したいと考えている方々には、次のようなステップで、SLOとリリース期間短縮のバランスをとることをおすすめします。
- システム境界を識別する
ユーザーに公開されている機能ごとに、一つひとつのまとまりとしてシステム境界を識別します。この境界で区切られた要素ごとに、サービスレベル指標であるSLI（Service Level Indicators）とSLOを設定することになります。
- システム境界で提供される機能を定義する
各コンポーネントを論理単位（UI/APIティア、ログインサービス、データ・ストレージ/クエリティア、レガシーデータティア、データインジェスト、ルーティングなど）でまとめて、それぞれのシステム境界で提供される機能を明確にします。
- 各機能の可用性を定義する
各機能に何が期待されているのか、可用性を明確に定義します。平易な言葉を使い、専門家でなくとも理解できるよう表現することが大切です。
- SLIを設定する
各機能に対して、SLIを設定します。例えば「特定の宛先にメッセージを送る機能」であれば、配信までに要した時間を定義するという具合です。
- ベースラインデータを取得する
モニタリングを行い、それぞれのSLIのベースラインデータを取得して、目標を達成できたかどうかをチェックします。
- SLOのターゲットを設定する
データを取得したら、SLOのターゲットを設定します。その際、サービスを受けるユーザーが何を期待しているのかを特定し、それを満たすためにSLOをどのように対応させるかを考える必要があります。
- 微調整と反復
設定したSLIとSLOは、固定されたものではありません。サービスの提供状況や顧客ニーズなどを反映して、常に微調整と反復を続けていくことが大切です。
ポイント3：公正かつ効果的なオンコールポリシーの作成
DevOpsを効果的に実践するためには、エンジニアが生産性高く維持して、安心して働ける環境づくりが必要になります。そこで、重要になるのがオンコールポリシーの改善、つまり不測のインシデントに対応するエンジニアへの呼び出しに関する基準づくりの見直しです。
オンコールポリシーを作成するにあたり、チーム内でオンコールに対して誰が対応するかを公正に組織化・構造化しておくことが必要となります。対応メンバーはチーム内でローテーションするスタイルがよいでしょう。
そして、ここでも測定が重要です。インシデントに関連する各数値、例えば、呼び出し回数、呼び出し時間などのメトリクスを追跡し、対応できない呼び出し負荷がエンジニアにかかっていないかチェックするのです。もしも、負荷が大きいと判断されれば、サポートメンバーを増やすか、サービスを改善するかといった対応をとることになります。
また、オンコールポリシーを作成する際には、それが自社の状況に合っているかどうかを確認することが不可欠です。自社の現状にフィットした内容かどうかは、次のような項目で確認してみてください。
ポイント4：インシデント対応を目指した管理プロセスを作成
インシデントに対する明確なルールやプロセスがなく、適切に管理されていない場合、どうしても場あたり的な対応になってしまいます。こうした組織をそのままにしておくと、同じことが何度も起こり、そのたびにサービスの提供遅延や停止が繰り返されることになりかねません。これでは、DevOpsが目指す生産性や品質の向上が期待できません。
そこで、ユーザーへの被害を最小限にとどめ、なおかつエンジニアが効率的・効果的に対応するためには、インシデントを管理することが重要です。そのための管理プロセスの作成手順は下記のとおりです。
- インシデントの重要度を定義する
どの事象がどれほどの影響をどの範囲にまで及ぼすものなのか、インシデントの重要度を段階的に定義します。ユーザーへの影響がない低レベルのものから、サービス停止を招くものまで、レベル分けして設定してください。
- インシデントに対するモニターを用意する
インシデントをいち早く察知できる仕組みであるモニターを用意します。肝心なのは、ユーザーからクレームが入るよりも早く、インシデントを察知することです。先取りして対応できる体制が求められる部分です。
- レスポンダーロールを定義する
インシデントが起こった際、誰がどのように動くのかというレスポンダーロールを定義しておきます。これがあれば、いざというときにも誰が何をすべきかが明確になり、混乱せずに済みます。
- 包括的なタスクを定める
インシデントの発生から解決までの全体を通じて、各メンバーの役割ごとのタスクを定めておきます。ここには、相互のコミュニケーションのとり方や責任の分担も含まれます。
- 適切なツールを使い、サポート体制を組む
インシデント対応メンバーへの情報提供と、可能な部分は自動化するツールを用意するなどして、万全のサポート体制を構築しておきます。
ポイント5：マイクロサービスの複雑さを、どう克服するか
ソフトウェアのさまざまな機能が一体化されたモノリシックなサービスと比べると、各機能が分割されたマイクロサービスは、生産性や機能性を高めるという面でとても有利です。一方で、それぞれのマイクロサービスをどのように組み合わせ、連携させるかということには、十分な注意が払われていないケースも多いようです。
複雑な環境を簡素化し、チーム内だけではなく開発と運用のそれぞれにおけるコラボレーション環境とコミュニケーション課題を見直すことも、DevOpsを効果的に実践するポイントとなります。この点については、あらかじめ連携におけるルールを設定しておくべきでしょう。
例えば、個々のアプリケーションが正しく分離されているか、特定のサービスにおいてトラフィックが急激に上昇する現象がほかのサービスに伝播しているかなどを確かめることも重要です。これらは、データをチェックすることで、すべて知ることができます。
ポイント6：データの活用で、開発スピードを向上させる
DevOpsを有効に実践していくために留意すべきポイントは多くありますが、最も大切なことは「測定し、データを取り、活用していくこと」にあるといえます。その理由は単純で、データはあらゆる行動やプロセスの結果です。行動やプロセスが正しかったかどうかは、すべてデータに表れるからです。
DevOpsによる開発・運用のパフォーマンスを追跡すれば、正しい道を進んでいるかどうかがわかります。開発のスピード、リリースのタイミング、その頻度が適切なのかも判断できます。もっと広い視野でいえば、そのビジネスが人々に受け入れられているかどうか、望ましい結果を出せているかどうかもわかるでしょう。
DevOpsは開発スピードを向上させる手段ですが、エンジニアが適切で効果的な作業に集中でき、同時にソフトウェアのパフォーマンスとビジネスそのものを最適化するための、有効な手法でもあるのです。
DevOpsの課題に対するNew Relicの解決アプローチ
エンジニアがシステム全体をモニタリング、デバッグ、改善できるオブザーバビリティプラットフォームを提供するNew Relicでは、お客様からDevOpsへの問い合わせや相談が多々あります。その中で、多くの方々が共通してつまずくポイントがわかりました。
ここからは、よくあるDevOpsの課題に対して、New Relicの解決アプローチを3つご紹介します。これまでにご紹介したポイントと併せて、DevOpsを実践する際にお役立てください。
データのサイロ化を排除する
データのサイロ化を排除することで、DevOpsが効率的に実践できるようになります。
パフォーマンスの結果である測定データは、DevOpsを進めるにあたって中核をなすものです。しかし、データの捉え方や評価の仕方に差違があると、せっかくのデータがサイロ化してしまい、管理するスタッフ間の共通言語が崩れてしまうことがよくあります。
こうした状況を避けるには、どのSLOが最重要なのかをチーム内で合意形成しておき、全員が同じ方向へ進めるようにするのがいいでしょう。
複雑さを簡素化する
クラウドネイティブな環境では、多くのマイクロサービスが関連し連携し合うことで、開発スピードを加速させますが、多くの個別コンポーネントが絡み合う複雑さから業務が煩雑になりかねません。こうした複雑さを簡素化することも、効率的にDevOpsを実践するポイントのひとつです。
そこで、データを取得することによって、すべてのコンポーネントが正しく機能しているかどうかをチェックできます。データを見れば問題解決の糸口が見つかり、複雑な環境であっても業務を簡素化できるのです。
変更による影響の範囲を理解する
DevOpsでは、コードの変更が頻繁に行われ、サービスの機能と品質の向上が常に進められます。こうした環境で重要なのは、変更によって影響が及ぶ範囲を明確にし、理解しておくことです。言い換えれば、「変更による影響範囲を明確化できるデータを取得する」ということです。
影響範囲の明確化がなされていないと、異常が起こった際、初動対応の段階で、バックエンドからフロントエンドまでを、網羅的に調査しなくてはなりません。変更の影響範囲が明確であれば、局所的な調査で済み、効率的な障害対応が可能になるのです。
データを基盤としたハイパフォーマンスなDevOps体制を
現在のシステム開発では、DevOpsの概念はメインストリームといえるほどに普及してきました。開発スピードの速さと生産性の高さが求められる今、高品質を維持できることやイノベーションを生み出せる環境として、多くの企業で採用され始めています。中でも高い能力を持つチームは、ダウンタイムからの回復時間を大幅に短縮したり、高頻度なデプロイを実現したりしています。
こうしたハイパフォーマンスを実現するには、第一にデータです。現状を可視化し、継続的な改善を重ねていくためには何が必要なのか、それを分析できる基盤を構築しておくことが肝要です。
New Relicでは、2020年にDevOpsの実践ガイドをまとめています。これからDevOpsを実践していく方も、すでにDevOpsを実践しているがどのような効果が出ているのかがわからないという方にも、ぜひご覧いただければと思います。
次のステップ
- さらにDevOpsについてお知りになりたい方は、こちらのebookをお読みください。
(ebook) 「DevOpsチームを成功に導くためのベストプラクティス」
- New Relicでは、 無料のアカウントをご提供しています。無料アカウントには、毎月100GBのデータ取込み、1名のフルプラットフォームユーザー、および無制限の無料ベーシックユーザーが含まれます。ぜひご活用ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
