DevOps チェックリスト

  • [アーティクル]

DevOps とは、開発と品質保証と IT 運用を、統一されたカルチャと一連のプロセスに融合することによってソフトウェアを開発する手法です。 このチェックリストは、DevOps のカルチャとプロセスを評価するための出発点としてご利用ください。

カルチャ

組織とチームとの間で業務上の整合性を確保する。 リソース、目的、目標、優先度に対する認識が同じ組織内で異なっていると、運用上のリスクを招く場合があります。 業務、開発、運用のチームが認識を共有する必要があります。

チームがソフトウェア ライフ サイクルを確実に理解する。 アプリケーションの全体的なライフ サイクルと、そのライフ サイクル内での各アプリケーションの段階を、チームが理解する必要があります。 この情報があると、すべてのチーム メンバーが、今すべきことと、将来に向けて計画し、準備すべきことを把握できます。

サイクル時間を減らす。 アイデアから役に立つソフトウェアの開発までにかかる時間を最短にすることを目指します。 個々のリリースの規模と範囲を制限することで、テストの負荷を低く抑えてください。 ビルド、テスト、構成、デプロイのプロセスを、可能な限り自動化します。 開発者間や、開発者と運用チームの間のコミュニケーションの妨げとなるものを解消します。

プロセスを見直して改善する。 自動化されたものであれ、手動によるものであれ、プロセスと手順に決して完成はありません。 絶えず改善することを目的に、現行のワークフロー、手順、ドキュメントに対する定期的な見直しの機会を設けてください。

先を見越して計画する。 あらかじめ失敗を織り込んで計画します。 問題が発生したときにそれを迅速に特定し、対応にあたる正しいチーム メンバーに問題をエスカレートして、解決策を確認するためのプロセスを設けます。

失敗から学ぶ。 失敗は必ず起こるものですが、それを繰り返さないために失敗から学ぶことが大切です。 運用上の障害が発生した場合、問題をトリアージし、原因と解決策を文書化して、得られた教訓を共有します。 できれば、今後同じような障害が発生したときに自動的に検出できるように既存のビルド プロセスを更新しましょう。

スピードを最適化し、データを収集する。 計画した改善策はどれも仮説です。 できるだけ小規模な変更で作業します。 新しいアイデアは実験として扱います。 運用データを収集して実験の効果を評価できるよう、実験をインストルメント化します。 仮説が間違っていたら、フェイル ファストできるようにしておきます。

学ぶ時間を見込む。 失敗と成功は、どちらも学びの機会となります。 新しいプロジェクトに進む前に、重要な教訓を蓄積するための時間を見込み、それらの教訓が確実にチームに浸透するようにします。 チームがスキルの形成、実験、新しいツールや手法の習得を行うための時間を確保します。

操作を文書化する。 製品コードと同じ品質水準で、すべてのツール、プロセス、自動化タスクを文書化します。 サポートするシステムの現在の設計とアーキテクチャを、復旧プロセスや他のメンテナンス手順と併せて文書化します。 理論上最適なプロセスではなく、実際に行っている手順に注目します。 その文書を定期的に見直して更新します。 コードについては、意味のあるコメントが含まれていることを確認します (特にパブリック API の場合)。 可能な場合は、ツールを使用してコードの文書を自動的に生成します。

知識を共有する。 文書は、人々がその存在を把握し、見つけることができたときに初めて人の役に立ちます。 ドキュメントを整理し、簡単に見つけられるようにします。 ランチでの歓談 (非公式のプレゼンテーション)、ビデオ、ニュースレターなど、工夫して機会を設け知識を共有します。

開発

運用環境と同様の環境を開発者に提供する。 開発環境とテスト環境が運用環境と一致していないと、テストや問題の診断が難しくなります。 開発環境とテスト環境を、可能な限り運用環境に近い状態に保ちます。 テスト データは、実際の運用データではなくサンプル データであっても、運用環境で使うデータと矛盾がないようにします (プライバシーやコンプライアンス上の理由から)。 サンプル テスト データを生成して、匿名化することを検討してください。

権限のあるすべてのチーム メンバーが、インフラストラクチャをプロビジョニングし、アプリケーションをデプロイできるようにする。 運用環境と同様のリソースのセットアップや、アプリケーションのデプロイに、複雑なタスクや、システムに関する詳しい技術的知識が含まれていてはなりません。 適切なアクセス許可があればだれでも、運用チームに頼ることなく、運用環境と同様のリソースを作成またはデプロイできる必要があります。

この推奨事項は、だれでも運用デプロイにライブ更新をプッシュできるという意味ではありません。 運用環境と同様の環境の作成に関して、開発チームと QA チームに対する摩擦を減らすということです。

分析情報のために各アプリケーションをインストルメント化する。 アプリケーションの正常性を把握するには、その実行状況と、エラーや問題が発生しているかどうかを知る必要があります。 設計要件として常にインストルメンテーションを含め、各アプリケーションに最初からインストルメンテーションを組み込みます。 インストルメンテーションには、根本原因分析のためのイベント ログのほか、各アプリケーションの正常性と使用状況を監視するためのテレメトリとメトリックも含める必要があります。

技術的完成度の低い部分を追跡する。 多くのプロジェクトでは、程度の差はあっても、リリース スケジュールがコードの品質より優先されます。 ショートカットや他の最適ではない実装が行われたときは常に文書化し、それらの問題を再検討するための時間をスケジュールします。

運用環境に直接更新をプッシュすることを検討する。 全体的なリリース サイクル時間を短縮するため、適切にテストされたコードのコミットを直接運用環境にプッシュすることを検討します。 フィーチャー トグルを使って、有効にする機能を制御します。 そうすれば、トグルを使って機能を有効または無効にすることで、開発からリリースに素早く切り替えることができます。 また、トグルは、特定の機能を運用環境のサブセットにデプロイするカナリア リリースのようなテストを実行するときにも便利です。

テスト

テストを自動化する。 ソフトウェアを手動でテストするのは、面倒なうえに間違いが生じる可能性が高くなります。 頻繁に行うテスト タスクは自動化し、そのテストをビルド プロセスに統合します。 テストを自動化することで、テストの範囲と再現性に一貫性が保たれます。 統合 UI テストを実行するときも、自動ツールを使います。 Azure では、テストの構成と実行を支援する開発リソースとテスト リソースを用意しています。 詳しくは、「Azure での開発とテスト」をご覧ください。

障害に備えたテストを実施する。 システムがサービスに接続できない場合でも、システムは正常に応答する必要があります。 また、サービスが再び利用可能になったら、システムは復旧する必要があります。 テスト環境とステージング環境における標準的なレビューの一環として、フォールト挿入テストを実施してください。 テストのプロセスと手法が成熟してきたら、それらのテストを運用環境で実行することを検討します。

運用環境でテストする。 リリース プロセスは、運用環境へのデプロイで終わるわけではありません。 デプロイしたコードが、想定したとおりに機能することを確かめるためのテストを実施しましょう。 更新頻度の低いデプロイについては、運用テストを定期的なメンテナンスの一環としてスケジュールします。

パフォーマンス テストを自動化してパフォーマンスの問題を早期に把握する。 深刻なパフォーマンスの問題は、コードのバグと同じくらい重大な影響をもたらすことがあります。 アプリケーションのバグは自動化された機能テストで回避できますが、パフォーマンスの問題はこれらのテストでは検出されない可能性があります。 待ち時間、読み込み時間、リソース使用量など、各種のメトリックに関して、許容できるパフォーマンス目標を定義してください。 自動化されたパフォーマンス テストをリリース パイプラインに含めて、それらの目標をアプリケーションが満たしていることを確認します。

キャパシティ テストを実施する。 テスト条件下ではアプリケーションが正常に機能するものの、スケーラビリティやリソースの制限上、運用環境では問題が生じることがあります。 想定される最大のキャパシティと使用量の上限を必ず定義しましょう。 それらの上限にアプリケーションが対応できることをテストで確認するだけでなく、上限を超えたときに何が起こるかもテストします。 定期的にキャパシティ テストを行います。

初回リリース後、運用コードを更新するたびに、パフォーマンス テストとキャパシティ テストを行う必要があります。 履歴データを使ってテストを微調整し、行う必要があるテストの種類を特定します。

自動化されたセキュリティ侵入テストを実施する。 アプリケーションのセキュリティを確認することは、他の機能のテストと同じくらい大切です。 自動侵入テストを、ビルドおよびデプロイ プロセスの標準的な部分として実施します。 デプロイしたアプリケーションに対して定期的なセキュリティ テストと脆弱性スキャンをスケジュールし、開放ポート、エンドポイント、攻撃を監視します。 自動化されたテストによって、定期的に実施する詳細なセキュリティ レビューが不要になるわけではありません。

自動化されたビジネス継続性テストを実施する。 バックアップの回復とフェールオーバーを含む大規模なビジネス継続性のテストを作成します。 自動化されたプロセスを設けて、それらのテストを定期的に実施しましょう。

Release

デプロイを自動化する。 自動化には次のような多くの利点があります。

  • より速く信頼性の高いデプロイを実施できます。
  • テスト、ステージング、運用など、サポートされている環境への一貫したデプロイが保証されます。
  • 人手でデプロイすると発生する可能性があるヒューマン エラーのリスクがなくなります。
  • 都合に応じてリリースをスケジュールしやすくなり、可能性のあるダウンタイムの影響が最小限になります。

テスト、ステージング、運用環境に各アプリケーションをデプロイするプロセスを自動化します。 ロールアウト中の問題をすべて検出するためにシステムを所定の場所に配置し、修正のロールフォワードや変更のロールバックのための自動化された方法を用意します。

継続的インテグレーションを使用する。 継続的インテグレーション (CI) は、一元化されたコード ベースに対し、開発者のすべてのコードを定期的にマージし、標準的なビルド プロセスとテスト プロセスを自動的に実行する手法です。 CI によって、不整合を生じることなくチーム全体が同時にコード ベースの作業を行うことができます。 CI は、コードの欠陥をできるだけ早く見つけるのにも役立ちます。 できる限り、コードをコミットまたはチェックインするたびにCI プロセスを実行する必要があります。 少なくとも 1 日に 1 回実行する必要があります。

トランク ベースの開発モデルの導入を検討してください。 このモデルでは、開発者たちが単一のブランチ (トランク) に対してコミットします。 コミットによってビルドが損なわれないようにする必要があります。 このモデルでは、すべての機能の作業がトランク内で行われ、マージの競合は各コミットの時点で解決されるため、CI が円滑化されます。

継続的デリバリーの使用を検討する。 継続的配信 (CD) は、運用環境と同様の環境に対してコードのビルド、テスト、デプロイを自動的に行うことで常時デプロイ可能なコードを確保する手法です。 CD を追加して完全な CI/CD パイプラインを作成すると、コードの欠陥をできるだけ早く検出するのに役立ちます。 また、適切にテストされた更新プログラムを短時間でリリースできます。

継続的" デプロイ" とは、CI/CD パイプラインを経た更新プログラムを自動的に取得して運用環境にデプロイするプロセスです。 継続的デプロイには、堅牢な自動テストと高度なプロセス計画が必要です。 あらゆるチームに適しているとは限りません。

少しずつ漸進的な変更を行う。 大規模なコード変更を行うと、小規模な場合より、バグが発生する可能性が高くなります。 可能な限り、変更は小さいものに留めてください。 これにより、各変更の潜在的な影響が制限され、問題の把握とデバッグのタスクが簡単になります。

変更の公開を管理する。 更新プログラムがエンド ユーザーに提供されるタイミングを確実に管理します。 フィーチャー トグルを使って、エンド ユーザーに対して機能を有効にするタイミングを制御することを検討します。

リリース管理戦略を導入してデプロイのリスクを軽減する。 アプリケーションの更新プログラムを運用環境にデプロイする際には、常にある程度のリスクが伴います。 このリスクを最小限に抑えるには、カナリア リリースやブルーグリーン デプロイなどの戦略を使用して、更新プログラムをユーザーのサブセットにデプロイします。 各更新プログラムが想定どおりに動作することを確認した後、残りのシステムに各更新プログラムをロールアウトします。

すべての変更を文書化する。 軽微な更新や構成の変更が、混乱やバージョン管理の競合を引き起こす原因となる場合があります。 いかに小さな変更でも必ず、明確な記録を残すようにしましょう。 適用したパッチ、ポリシーの変更、構成の変更など、変更された点をすべて記録します。 変更の記録をチーム全員が見られるようにします。 ただし、これらのログには機密データを含めないでください。 たとえば、資格情報が更新されたことや、変更したユーザーは記録しますが、更新後の資格情報は記録しないでください。

インフラストラクチャをイミュータブルにすることを検討する。 不変インフラストラクチャは、運用環境にデプロイした後でインフラストラクチャを変更してはならないという原則に基づいています。 そうしないと、場当たりの変更が適用され、変更内容を正確に把握しづらくなる可能性があります。 イミュータブル インフラストラクチャは、新しいデプロイの一環として、サーバー全体を置き換えることによって実現されます。 この方法では、コードとホスティング環境をブロックとしてテストしてデプロイできます。 デプロイ後は、次のビルドとデプロイ サイクルまで、インフラストラクチャ コンポーネントを変更しません。

監視

システムを監視可能にする。 運用チームは、システムやサービスの正常性と状態を常に明確に把握しておく必要があります。 外部正常性エンドポイントを設定して状態を監視し、運用メトリックをインストルメント化するようにアプリケーションをコーディングします。 システムの枠を越えてイベントを相互に関連付けるのに役立つ一般的かつ一貫性のあるスキーマを使用しましょう。 Azure リソースの正常性と状態を追跡するための標準的な方法は、Azure Diagnostics と Application Insights を使うことです。 Azure Monitor でも、クラウドまたはハイブリッド ソリューション向けの一元化された監視および管理が提供されます。

ログとメトリックを集計して相互に関連付ける。 適切にインストルメント化されたテレメトリ システムからは、生のパフォーマンス データとイベント ログが大量に生成されます。 運用スタッフが常にシステムの正常性に関する最新情報を把握できるよう、テレメトリとログ データの処理と関連付けがシステムによって短時間で行われることを確認します。 問題の全体像を把握でき、イベントの相互関係がわかるように、データを整理して表示します。

データの処理方法とデータの保存期間に関する要件について、会社の保持ポリシーを確認します。

自動化されたアラートと通知を実装する。 Monitor のような監視ツールを設定して、潜在的な問題や現在の問題を示すパターンや状態を検出します。 問題に対処できるチーム メンバーにアラートを送信します。 誤検知を避けるためにアラートは調整しましょう。

資産とリソースの有効期限を監視する。 証明書など、一部のリソースと資産には有効期限があります。 有効期限の切れる資産と具体的な期限、その資産に依存しているサービスまたは機能を確実に追跡してください。 これらの資産は、自動化されたプロセスを使用して監視します。 資産の有効期限が切れる前に運用チームに通知し、期限切れによってアプリケーションが損なわれる恐れがある場合は、状況をエスカレートします。

管理

運用タスクを自動化する。 反復的な運用プロセスを手動で処理していると、間違いが生じやすくなります。 一定の実行と品質を確保するために、そうしたタスクはできる限り自動化しましょう。 ソース管理を使って、自動化を実装するコードをバージョン管理します。 他のコードと同様に、自動化ツールをテストします。

コードとしてのインフラストラクチャのアプローチをプロビジョニングに採用する。 リソースのプロビジョニングに必要な手動構成を、できるだけ少なくします。 代わりに、スクリプトや Azure Resource Manager テンプレートを使用してください。 保守する他のすべてのコードと同様に、スクリプトとテンプレートをソース管理で維持します。

コンテナーの使用を検討する。 コンテナーには、アプリケーションをデプロイするための標準的なパッケージベースのインターフェイスが用意されています。 コンテナーを使用する場合は、アプリケーションの実行に必要なソフトウェア、依存関係、ファイルを含む自己完結型パッケージを使用してアプリケーションをデプロイします。 この方法により、デプロイ プロセスが大幅に簡素化されます。

また、コンテナーは、アプリケーションとその基になるオペレーティング システムとの間に抽象化レイヤーを形成し、環境間の一貫性を提供します。 また、この抽象化によって、ホスト上で実行されている他のプロセスやアプリケーションからコンテナーを分離することができます。

回復性と自己復旧機能を実装する。 回復性は、障害から回復するアプリケーションの能力です。 回復性の方法には、たとえば一時的なエラーの再試行やセカンダリ インスタンス (場合によっては別のリージョン) へのフェールオーバーがあります。 詳しくは、「信頼性の高い Azure アプリケーションを設計する」をご覧ください。 アプリケーションをインストルメント化し、機能停止や他のシステム障害を管理できるよう、問題を即座に報告します。

運用マニュアルを用意する。 運用マニュアルまたは Runbook は、運用スタッフがシステムを保守するために必要な手順や管理情報を文書化したものです。 その他あらゆる運用シナリオが文書化されるほか、サービスの障害など、中断が生じたときに役に立つ軽減計画も文書化されます。 このドキュメントを開発プロセスの間に作成し、以後、最新の状態に保ちます。 これらのリソースは、定期的にレビュー、テスト、改善する必要のある生きたドキュメントとして扱います。

文書が共有されることがきわめて重要となります。 各自が持つ知識を提供し、共有するようチーム メンバーに奨励してください。 チーム全員がドキュメントにアクセスできる必要があります。 チームのメンバーのだれもが簡単に文書を更新できるようにしてください。

オンコール手順を文書化する。 オンコールの職務、スケジュール、手順を確実に文書化し、すべてのチーム メンバーと共有します。 この情報は常に最新の状態に保ちます。

サードパーティの依存関係のエスカレーション手順を文書化する。 直接制御できない外部のサードパーティ サービスにアプリケーションが依存している場合、機能停止への対応計画を立てる必要があります。 計画した軽減プロセスの文書を作成しましょう。 サポートの連絡先とエスカレーション パスを含めるようにしてください。

構成管理を使用する。 構成の変更を計画し、運用が認識できるようにして、それらを記録します。 これらの目的には、構成管理データベースまたはコードとしての構成アプローチを使用できます。 構成を定期的に監査して、望ましい設定が実際に行われていることを確認します。

Azure サポート プランを取得し、サポート プロセスを理解する。 Azure には多くのサポート プランが用意されています。 ニーズに適したプランを決定し、チーム全体がプランの使用方法を理解するようにします。 チームのメンバーがプランについて細部まで理解し、サポート プロセスの具体的な流れや、Azure のサポート チケットを申請する方法を把握していることが大切です。 大きなイベントが予測される場合は、サービス制限の引き上げを Azure サポートにご相談ください。 詳しくは、「Azure サポート プランに関する FAQ」をご覧ください。

リソースへのアクセス権を付与する際は最小限の特権の原則に従う。 リソースへのアクセス権は慎重に管理してください。 ユーザーにリソースへのアクセス権を明示的に付与しない限り、アクセスを既定で拒否します。 ユーザーがタスクの遂行に必要なアクセス権だけを付与します。 ユーザーのアクセス許可を追跡し、定期的にセキュリティ監査を実施してください。

Azure ロールベースのアクセス制御の使用。 リソースへのユーザー アカウントとアクセス権の割り当てを手動のプロセスで実施することは避けてください。 Azure のロールベースのアクセス制御 (Azure RBAC) を使用し、Microsoft Entra ID の ID とグループに基づくアクセス権を付与します。

バグ追跡システムを使用して問題を追跡する。 適切な方法で問題を追跡しないと、すぐに見落としや重複する作業、別の問題につながります。 担当者どうしの略式のやり取りで、バグの状態を追跡することは避けてください。 バグ追跡ツールを使って問題の詳細を記録し、それに対応するリソースを割り当て、進行状況や状態の監査証跡を残すようにしましょう。

すべてのリソースを変更管理システムで管理する。 DevOps プロセスのすべての側面を管理およびバージョン管理システムに含めると、変更を簡単に追跡および監査できます。 コード、インフラストラクチャ、構成、ドキュメント、スクリプトを含めます。 テスト、ビルド、レビューのプロセス全体を通して、これらすべての種類のリソースをコードとして扱います。

チェックリストを使用する。 運用チェックリストは、プロセスに従うのに役立ちます。 大量のマニュアルでは見落としが発生しやすくなりますが、チェックリストに従うと、他の方法では見過ごされがちな細部に注意を喚起できます。 チェックリストはメンテナンスしてください。タスクを自動化してプロセスを合理化する方法がないか、絶えず模索するようにしましょう。

次のステップ