DevOps チェックリストDevOps Checklist

DevOps とは、開発と品質保証と IT 運用を、統一されたカルチャと一連のプロセスに融合することによってソフトウェアを開発する手法です。DevOps is the integration of development, quality assurance, and IT operations into a unified culture and set of processes for delivering software. このチェックリストは、DevOps のカルチャとプロセスを評価するための出発点としてご利用ください。Use this checklist as a starting point to assess your DevOps culture and process.

カルチャCulture

組織とチームとの間で業務上の整合性を確保する。Ensure business alignment across organizations and teams. リソース、目的、目標、優先度に対する認識が同じ組織内で異なっていると、運用上のリスクを招く場合があります。Conflicts over resources, purpose, goals, and priorities within an organization can be a risk to successful operations. 業務、開発、運用のすべてのチームが認識を共有する必要があります。Ensure that the business, development, and operations teams are all aligned.

チーム全体でソフトウェア ライフサイクルを確実に理解する。Ensure the entire team understands the software lifecycle. アプリケーションの全体的なライフサイクルがどのようなもので、現在アプリケーションがどの段階にあるかをチームで理解する必要があります。Your team needs to understand the overall lifecycle of the application, and which part of the lifecycle the application is currently in. そのことは、今すべきこと、そして将来に向けて計画し、準備すべきことをチームのメンバー全員が把握することにつながります。This helps all team members know what they should be doing now, and what they should be planning and preparing for in the future.

サイクル時間を減らす。Reduce cycle time. 極力時間を短縮する目的は、アイデアを使用に適したソフトウェアの開発へと進展させるためです。Aim to minimize the time it takes to move from ideas to usable developed software. 個々のリリースの規模と範囲を制限することで、テストの負荷を低く抑えてください。Limit the size and scope of individual releases to keep the test burden low. ビルド、テスト、構成、デプロイの各プロセスは、可能な限り自動化します。Automate the build, test, configuration, and deployment processes whenever possible. 開発者間や、開発者と運用担当者との間の意思疎通の妨げとなる要素があれば解消してください。Clear any obstacles to communication among developers, and between developers and operations.

プロセスを見直して改善する。Review and improve processes. 自動化されたものであれ、手動によるものであれ、プロセスと手順に決して完成はありません。Your processes and procedures, both automated and manual, are never final. 絶えず改善することを目的に、現行のワークフロー、手順、ドキュメントに対する定期的な見直しの機会を設けてください。Set up regular reviews of current workflows, procedures, and documentation, with a goal of continual improvement.

先を見越して計画する。Do proactive planning. あらかじめ失敗を織り込んで計画します。Proactively plan for failure. 問題が発生したときにそれを迅速に特定し、対応にあたる正しいチーム メンバーにエスカレートして、解決策を確認するためのプロセスを設けておきましょう。Have processes in place to quickly identify issues when they occur, escalate to the correct team members to fix, and confirm resolution.

失敗から学ぶ。Learn from failures. 失敗は必ず起こるものですが、それを繰り返さないために失敗から学ぶことが大切です。Failures are inevitable, but it's important to learn from failures to avoid repeating them. 運用上の障害が発生した場合、問題をトリアージし、原因と解決策を文書化して、得られた教訓があれば共有します。If an operational failure occurs, triage the issue, document the cause and solution, and share any lessons that were learned. できれば、今後同じ種類の障害が発生したときに自動的に検出できるように既存のビルド プロセスを更新しましょう。Whenever possible, update your build processes to automatically detect that kind of failure in the future.

スピードを最適化し、データを収集する。Optimize for speed and collect data. 計画した改善策はどれも仮説です。Every planned improvement is a hypothesis. できるだけ小さな間隔で実施するようにしましょう。Work in the smallest increments possible. 新しいアイデアは実験として扱います。Treat new ideas as experiments. 運用データを収集してその効果を評価できるよう実験をインストルメント化してください。Instrument the experiments so that you can collect production data to assess their effectiveness. 仮説が間違っていたら、フェイル ファストする覚悟が必要です。Be prepared to fail fast if the hypothesis is wrong.

学ぶ時間を見込む。Allow time for learning. 失敗と成功は、どちらも良い学びの機会です。Both failures and successes provide good opportunities for learning. 新しいプロジェクトに進む前に、重要な教訓を蓄積するための時間を十分に見込み、それらの教訓が確実にチームに浸透するようにしましょう。Before moving on to new projects, allow enough time to gather the important lessons, and make sure those lessons are absorbed by your team. チームがスキルを形成する時間や、実験する時間、新しいツールや手法を身に付ける時間も確保してください。Also give the team the time to build skills, experiment, and learn about new tools and techniques.

操作を文書化する。Document operations. 製品コードと同じ品質水準で、すべてのツール、プロセス、自動化タスクを文書化します。Document all tools, processes, and automated tasks with the same level of quality as your product code. 実際にサポートするシステムの現在の設計とアーキテクチャを、復旧プロセスなどの各種のメンテナンス手順と併せて文書化します。Document the current design and architecture of any systems you support, along with recovery processes and other maintenance procedures. 理論上最適なプロセスではなく、実際に自分が実行する手順に重点を置いてください。Focus on the steps you actually perform, not theoretically optimal processes. その文書を定期的に見直して更新します。Regularly review and update the documentation. コードに関して、特にパブリック API では、有意義なコメントが含まれていることを確認してください。コード ドキュメントは、できるだけツールを使用して自動的に生成しましょう。For code, make sure that meaningful comments are included, especially in public APIs, and use tools to automatically generate code documentation whenever possible.

知識を共有する。Share knowledge. 文書は、人々がその存在を把握し、見つけることができたときに初めて人の役に立ちます。Documentation is only useful if people know that it exists and can find it. 文書が整理されていて、見つけやすいことが大切です。Ensure the documentation is organized and easily discoverable. ランチでの歓談(非公式のプレゼンテーション)、ビデオ、ニュースレターなど、工夫して機会を設け知識を共有します。Be creative: Use brown bags (informal presentations), videos, or newsletters to share knowledge.

開発Development

運用環境と同様の環境を開発者に提供する。Provide developers with production-like environments. 開発環境とテスト環境が運用環境と一致しないと、問題をテストして診断することが難しくなります。If development and test environments don't match the production environment, it is hard to test and diagnose problems. そのため開発環境とテスト環境は、できるだけ運用環境に近い状態に保つようにしてください。Therefore, keep development and test environments as close to the production environment as possible. テスト データは、運用環境で使用されているデータと矛盾がないようにしてください。(プライバシーやコンプライアンス上の理由から) 実際の運用データではなくサンプル データであっても同様です。Make sure that test data is consistent with the data used in production, even if it's sample data and not real production data (for privacy or compliance reasons). サンプル テスト データを生成して、匿名化することを検討してください。Plan to generate and anonymize sample test data.

権限のあるすべてのチーム メンバーがインフラストラクチャのプロビジョニングとアプリケーションのデプロイに対応できるよう徹底する。Ensure that all authorized team members can provision infrastructure and deploy the application. 運用環境と同様のリソースをセットアップしたりアプリケーションをデプロイしたりするために、システムに関する詳しい技術知識や手動での複雑なタスクが要求されるのは好ましくありません。Setting up production-like resources and deploying the application should not involve complicated manual tasks or detailed technical knowledge of the system. 適切な権限さえあればだれでも、運用チームの協力を仰ぐことなく、運用環境と同様のリソースを作成またはデプロイできることが必要です。Anyone with the right permissions should be able to create or deploy production-like resources without going to the operations team.

この推奨事項は、運用環境にライブ更新をだれでもプッシュできるという意味ではありません。This recommendation doesn't imply that anyone can push live updates to the production deployment. 大切なのは、開発チームと QA チームの摩擦を減らして運用環境と同様の環境を作成することです。It's about reducing friction for the development and QA teams to create production-like environments.

アプリケーションをインストルメント化して洞察を得る。Instrument the application for insight. アプリケーションの正常性を把握するためには、それがどのように実行されているか、またエラーや問題が発生しているかどうかを知る必要があります。To understand the health of your application, you need to know how it's performing and whether it's experiencing any errors or problems. 設計要件として必ずインストルメンテーションを含め、アプリケーションに最初からインストルメンテーションを組み込むようにします。Always include instrumentation as a design requirement, and build the instrumentation into the application from the start. インストルメンテーションには、根本原因分析に使用するイベント ログのほか、アプリケーションの全体的な正常性と使用状況を監視するためのテレメトリとメトリックを含める必要があります。Instrumentation must include event logging for root cause analysis, but also telemetry and metrics to monitor the overall health and usage of the application.

技術的完成度の低い部分を追跡する。Track your technical debt. 多くのプロジェクトでは、程度の差こそあれ、リリース スケジュールがコード品質よりも優先されることがあります。In many projects, release schedules can get prioritized over code quality to one degree or another. そのようなことが起こったら必ず追跡してください。Always keep track when this occurs. ショートカットや他の最適でない実装があれば文書化し、将来、それらの問題を再検討するための時間をスケジュールしましょう。Document any shortcuts or other suboptimal implementations, and schedule time in the future to revisit these issues.

運用環境に直接更新をプッシュすることを検討する。Consider pushing updates directly to production. 全体的なリリース サイクル時間を抑えるため、適切にテストされたコードのコミットを直接運用環境にプッシュすることを検討してください。To reduce the overall release cycle time, consider pushing properly tested code commits directly to production. どの機能を有効にするかを制御するには、フィーチャー トグルを使用します。Use feature toggles to control which features are enabled. トグルを使用して機能を有効または無効にすることで、開発からリリースへと直ちに切り替えることができます。This allows you to move from development to release quickly, using the toggles to enable or disable features. トグルはまた、カナリア リリース (この場合は、特定の機能が運用環境のサブセットにデプロイされます) などのテストを実行するときにも有効です。Toggles are also useful when performing tests such as canary releases, where a particular feature is deployed to a subset of the production environment.

テストTesting

テストを自動化する。Automate testing. ソフトウェアを手動でテストするのは、面倒なうえに間違いが生じる可能性が高くなります。Manually testing software is tedious and susceptible to error. 頻繁に行うテスト タスクは自動化し、そのテストをビルド プロセスに統合しましょう。Automate common testing tasks and integrate the tests into your build processes. テストを自動化することで、テストの範囲と再現性に一貫性が保たれます。Automated testing ensures consistent test coverage and reproducibility. 統合された UI テストも自動ツールで実行することをお勧めします。Integrated UI tests should also be performed by an automated tool. Azure では、テストの構成と実行を支援する開発リソースとテスト リソースを用意しています。Azure offers development and test resources that can help you configure and execute testing. 詳細については、「開発とテスト」を参照してください。For more information, see Development and test.

障害に備えたテストを実施する。Test for failures. サービスに接続できなくなった場合のシステムの反応を考えてみましょう。If a system can't connect to a service, how does it respond? サービスが再び利用可能な状態になった後で回復できるでしょうか。Can it recover once the service is available again? テスト環境とステージング環境における標準的なレビューの一環として、フォールト挿入テストを実施してください。Make fault injection testing a standard part of review on test and staging environments. テストのプロセスと手法が成熟してきたら、それらのテストを運用環境で実行することを検討します。When your test process and practices are mature, consider running these tests in production.

運用環境でテストする。Test in production. リリース プロセスは運用環境にデプロイしたらそれで終わりというわけではありません。The release process doesn't end with deployment to production. デプロイしたコードが、想定したとおりに機能することを確かめるためのテストを実施しましょう。Have tests in place to ensure that deployed code works as expected. 更新頻度の低いデプロイについては、運用テストを定期的なメンテナンスの一環としてスケジュールします。For deployments that are infrequently updated, schedule production testing as a regular part of maintenance.

パフォーマンス テストを自動化してパフォーマンスの問題を早期に把握する。Automate performance testing to identify performance issues early. 深刻なパフォーマンスの問題は、コードのバグと同じくらい重大な影響をもたらすことがあります。The impact of a serious performance issue can be as severe as a bug in the code. 自動化された機能テストによってアプリケーションのバグは回避できますが、パフォーマンスの問題は検出できない可能性があります。While automated functional tests can prevent application bugs, they might not detect performance problems. 待ち時間、読み込み時間、リソース使用量など、各種のメトリックに関して、許容できるパフォーマンス目標を定義してください。Define acceptable performance goals for metrics like latency, load times, and resource usage. 自動化されたパフォーマンス テストをリリース パイプラインに含めて、それらの目標をアプリケーションが満たしていることを確認します。Include automated performance tests in your release pipeline, to make sure the application meets those goals.

キャパシティ テストを実施する。Perform capacity testing. テスト条件下ではアプリケーションが正常に機能するものの、スケーラビリティやリソースの制限上、運用環境では問題が生じることがあります。An application might work fine under test conditions, and then have problems in production due to scale or resource limitations. 想定される最大のキャパシティと使用量の上限を必ず定義しましょう。Always define the maximum expected capacity and usage limits. それらの上限にアプリケーションが対応できることをテストで確認するだけでなく、上限を超えたときに何が起こるかをテストしてください。Test to make sure the application can handle those limits, but also test what happens when those limits are exceeded. キャパシティ テストは定期的に実施する必要があります。Capacity testing should be performed at regular intervals.

初回リリース後、運用環境のコードを更新する際は必ずパフォーマンス テストとキャパシティ テストを実施することをお勧めします。After the initial release, you should run performance and capacity tests whenever updates are made to production code. 履歴データを使ってテストを微調整し、実施する必要のあるテストの種類を特定します。Use historical data to fine-tune tests and to determine what types of tests need to be performed.

自動化されたセキュリティ侵入テストを実施する。Perform automated security penetration testing. アプリケーションのセキュリティを確保することは、他の機能をテストすることと同じくらい大切です。Ensuring your application is secure is as important as testing any other functionality. 自動化された侵入テストを、標準的なビルドおよびデプロイ プロセスの一環として実施してください。Make automated penetration testing a standard part of the build and deployment process. デプロイしたアプリケーションに対して定期的なセキュリティ テストと脆弱性スキャンをスケジュールし、開放ポート、エンドポイント、攻撃を監視します。Schedule regular security tests and vulnerability scanning on deployed applications, monitoring for open ports, endpoints, and attacks. 自動化されたテストによって、定期的に実施する詳細なセキュリティ レビューが不要になるわけではありません。Automated testing does not remove the need for in-depth security reviews at regular intervals.

自動化されたビジネス継続性テストを実施する。Perform automated business continuity testing. バックアップの回復とフェールオーバーを含む大規模なビジネス継続性のテストを作成します。Develop tests for large-scale business continuity, including backup recovery and failover. 自動化されたプロセスを設けて、それらのテストを定期的に実施しましょう。Set up automated processes to perform these tests regularly.

ReleaseRelease

デプロイを自動化する。Automate deployments. テスト環境、ステージング環境、運用環境へのアプリケーションのデプロイを自動化します。Automate deploying the application to test, staging, and production environments. 自動化することによってデプロイの期間が短縮され、信頼性が向上するほか、サポートされるすべての環境でデプロイの一貫性が確保されます。Automation enables faster and more reliable deployments, and ensures consistent deployments to any supported environment. 手動でデプロイすることによって生じる人為的ミスのリスクを取り除くことができます。It removes the risk of human error caused by manual deployments. また、都合に応じたリリース スケジュールが立てやすくなるので、ダウンタイムが生じた場合の影響を最小限に抑えることができます。It also makes it easy to schedule releases for convenient times, to minimize any effects of potential downtime. ロールアウト中の問題をすべて検出するためにシステムを所定の場所に配置し、修正のロールフォワードや変更のロールバックのための自動化された方法を用意します。Have systems in place to detect any problems during rollout, and have an automated way to roll forward fixes or roll back changes.

継続的インテグレーションを使用する。Use continuous integration. 継続的インテグレーション (CI) は、一元化されたコードベースに対し、開発者のすべてのコードを定期的にマージし、標準的なビルド プロセスとテスト プロセスを自動的に実行する手法です。Continuous integration (CI) is the practice of merging all developer code into a central codebase on a regular schedule, and then automatically performing standard build and test processes. CI によって、不整合を生じることなくチーム全体が同時にコードベースの作業に取り組むことができます。CI ensures that an entire team can work on a codebase at the same time without having conflicts. コードの欠陥も、早い段階で確実に発見することが可能です。It also ensures that code defects are found as early as possible. できれば CI プロセスは、コードをコミットするときやチェックインするときに毎回実行することをお勧めします。Preferably, the CI process should run every time that code is committed or checked in. 少なくとも 1 日に 1 回は実行してください。At the very least, it should run once per day.

トランク ベースの開発モデルの導入を検討してください。Consider adopting a trunk based development model. このモデルでは、開発者たちが単一のブランチ (トランク) に対してコミットします。In this model, developers commit to a single branch (the trunk). その要件として、コミットによってビルドに支障が生じない、ということがあります。There is a requirement that commits never break the build. このモデルでは、すべての機能の作業がトランク内で実行され、マージの競合が生じてもコミット時に解決されるため、CI が円滑化されます。This model facilitates CI, because all feature work is done in the trunk, and any merge conflicts are resolved when the commit happens.

継続的デリバリーの使用を検討する。Consider using continuous delivery. 継続的配信 (CD) は、運用環境と同様の環境に対してコードのビルド、テスト、デプロイを自動的に行うことで常時デプロイ可能なコードを確保する手法です。Continuous delivery (CD) is the practice of ensuring that code is always ready to deploy, by automatically building, testing, and deploying code to production-like environments. 継続的デリバリーを追加して CI/CD の完全なパイプラインを形成することで、コードの欠陥を早期に検出しやすくなり、適切にテストされた更新プログラムをごく短期間でリリースすることができます。Adding continuous delivery to create a full CI/CD pipeline will help you detect code defects as soon as possible, and ensures that properly tested updates can be released in a very short time.

継続的 "デプロイ" は、CI/CD パイプラインを経た更新プログラムを自動的に取得して運用環境にデプロイする追加のプロセスです。Continuous deployment is an additional process that automatically takes any updates that have passed through the CI/CD pipeline and deploys them into production. 継続的デプロイは、堅牢な自動テストと高度なプロセス計画を必要とし、すべてのチームに適しているとは限りません。Continuous deployment requires robust automatic testing and advanced process planning, and may not be appropriate for all teams.

少しずつ漸進的な変更を行う。Make small incremental changes. 大規模なコード変更を行うと、バグが発生する可能性が高くなります。Large code changes have a greater potential to introduce bugs. 可能な限り、変更は小さいものに留めてください。Whenever possible, keep changes small. そうすることで、個々の変更によって影響が生じる可能性を抑え、問題の把握とデバッグがしやすくなります。This limits the potential effects of each change, and makes it easier to understand and debug any issues.

変更の公開を管理する。Control exposure to changes. 更新プログラムがエンド ユーザーの目に触れるタイミングを確実に管理しましょう。Make sure you're in control of when updates are visible to your end users. フィーチャー トグルを使用して、エンド ユーザーが機能を利用できるようになるタイミングを管理することを検討してください。Consider using feature toggles to control when features are enabled for end users.

リリース管理戦略を導入してデプロイのリスクを軽減する。Implement release management strategies to reduce deployment risk. アプリケーションの更新プログラムを運用環境にデプロイする際には、常にある程度のリスクが伴います。Deploying an application update to production always entails some risk. このリスクを最小限に抑えるには、カナリア リリースブルーグリーン デプロイなどの戦略を使用して、更新プログラムをユーザーのサブセットにデプロイします。To minimize this risk, use strategies such as canary releases or blue-green deployments to deploy updates to a subset of users. 想定したとおりに更新プログラムが動作することを確認したうえで、残りのシステムに更新プログラムをロールアウトしてください。Confirm the update works as expected, and then roll the update out to the rest of the system.

すべての変更を文書化する。Document all changes. 軽微な更新や構成の変更が、混乱やバージョン管理の競合を引き起こす原因となる場合があります。Minor updates and configuration changes can be a source of confusion and versioning conflict. いかに小さな変更でも必ず、明確な記録を残すようにしましょう。Always keep a clear record of any changes, no matter how small. 適用したパッチ、ポリシーの変更、構成の変更など、生じた変更はすべて記録してください。Log everything that changes, including patches applied, policy changes, and configuration changes. (ただし、それらのログには機密データを含めないようにしてください。(Don't include sensitive data in these logs. たとえば、資格情報が更新された事実や、変更を加えたユーザーは記録しますが、更新後の資格情報は記録しないでください。)変更の記録をチーム全員が閲覧できるようにしてください。For example, log that a credential was updated, and who made the change, but don't record the updated credentials.) The record of the changes should be visible to the entire team.

インフラストラクチャをイミュータブルにすることを検討する。Consider making infrastructure immutable. イミュータブル インフラストラクチャは、運用環境にデプロイした後にインフラストラクチャを変更すべきではないという原則です。Immutable infrastructure is the principle that you shouldn't modify infrastructure after it's deployed to production. そうしないと、場当たりの変更が適用され、変更内容を正確に把握しづらくなる可能性があります。Otherwise, you can get into a state where ad hoc changes have been applied, making it hard to know exactly what changed. イミュータブル インフラストラクチャは、新しいデプロイの一環として、サーバー全体を置き換えることによって実現されます。Immutable infrastructure works by replacing entire servers as part of any new deployment. そうすることで、コードとそのホストとなる環境を 1 つのブロックとしてテストし、デプロイすることができます。This allows the code and the hosting environment to be tested and deployed as a block. いったんデプロイしたインフラストラクチャ コンポーネントは、次のビルド/デプロイ サイクルまで変更されません。Once deployed, infrastructure components aren't modified until the next build and deploy cycle.

監視Monitoring

システムを監視可能にする。Make systems observable. 運用チームは、システムやサービスの正常性と状態を絶えず明確に把握しておく必要があります。The operations team should always have clear visibility into the health and status of a system or service. 状態を監視するための外部の正常性エンドポイントをセットアップすると共に、運用上のメトリックをインストルメント化するようアプリケーションをコーディングしてください。Set up external health endpoints to monitor status, and ensure that applications are coded to instrument the operations metrics. システムの枠を越えてイベントを相互に関連付けるのに役立つ一般的かつ一貫性のあるスキーマを使用しましょう。Use a common and consistent schema that helps you correlate events across systems. Azure Diagnostics および Application Insights は、Azure リソースの正常性や状態を追跡するための標準の方法です。Azure Diagnostics and Application Insights are the standard method of tracking the health and status of Azure resources. Microsoft Operation Management Suite もまた、クラウドまたはハイブリッド ソリューションに対する一元化された監視および管理を提供します。Microsoft Operation Management Suite also provides centralized monitoring and management for cloud or hybrid solutions.

ログとメトリックを集計して相互に関連付ける。Aggregate and correlate logs and metrics. 適切にインストルメント化されたテレメトリ システムからは、生のパフォーマンス データとイベント ログが大量に生成されます。A properly instrumented telemetry system will provide a large amount of raw performance data and event logs. テレメトリ データとログ データの処理と相互の関連付けが短時間で実行され、システムの正常性に関して、常に最新の情報を運用スタッフが把握できることを確認してください。Make sure that telemetry and log data is processed and correlated in a short period of time, so that operations staff always have an up-to-date picture of system health. 問題の全体像が把握できるようにデータを整理して表示し、イベントが互いに関連している場合にはそれが可能な限り明らかになるようにします。Organize and display data in ways that give a cohesive view of any issues, so that whenever possible it's clear when events are related to one another.

データの処理方法と必要な保持期間に関する要件については、会社の保持ポリシーを参照してください。Consult your corporate retention policy for requirements on how data is processed and how long it should be stored.

自動化されたアラートと通知を実装する。Implement automated alerts and notifications. 潜在的な問題や現在の問題を示すパターンまたは条件を検出し、問題に対処できるチーム メンバーにアラートを送信するには、Azure Monitor などの監視ツールを設定します。Set up monitoring tools like Azure Monitor to detect patterns or conditions that indicate potential or current issues, and send alerts to the team members who can address the issues. 誤検知を避けるためにアラートは調整しましょう。Tune the alerts to avoid false positives.

資産とリソースの有効期限を監視する。Monitor assets and resources for expirations. 証明書などの一部のリソースと資産は、一定期間が経過すると有効期限が切れます。Some resources and assets, such as certificates, expire after a given amount of time. 有効期限の切れる資産と具体的な期限、その資産に依存しているサービスまたは機能を確実に追跡してください。Make sure to track which assets expire, when they expire, and what services or features depend on them. これらの資産は、自動化されたプロセスを使用して監視します。Use automated processes to monitor these assets. 資産の有効期限が切れる前に運用チームに伝え、有効期限によってアプリケーションの中断が生じるおそれがあるかどうかをエスカレートしてください。Notify the operations team before an asset expires, and escalate if expiration threatens to disrupt the application.

管理Management

運用タスクを自動化する。Automate operations tasks. 反復的な運用プロセスを手動で処理していると、間違いが生じやすくなります。Manually handling repetitive operations processes is error-prone. 一定の実行と品質を確保するために、そうしたタスクはできる限り自動化しましょう。Automate these tasks whenever possible to ensure consistent execution and quality. その自動化を実装するコードは、ソース管理でバージョン管理することをお勧めします。Code that implements the automation should be versioned in source control. 他のあらゆるコードと同様、自動化ツールはテストする必要があります。As with any other code, automation tools must be tested.

コードとしてのインフラストラクチャのアプローチをプロビジョニングに採用する。Take an infrastructure-as-code approach to provisioning. リソースのプロビジョニングに必要な手動による構成は、できるだけ少なくしましょう。Minimize the amount of manual configuration needed to provision resources. 代わりに、スクリプトや Azure Resource Manager テンプレートを使用してください。Instead, use scripts and Azure Resource Manager templates. スクリプトとテンプレートは、保守の対象となる他のすべてのコードと同様にソース管理してください。Keep the scripts and templates in source control, like any other code you maintain.

コンテナーの使用を検討する。Consider using containers. コンテナーには、アプリケーションをデプロイするための標準的なパッケージベースのインターフェイスが用意されています。Containers provide a standard package-based interface for deploying applications. コンテナーを使用した場合、アプリケーションは、その実行に必要なソフトウェアや依存関係、ファイルなどをすべて含んだ自己完結型のパッケージを使用してデプロイされるため、デプロイ プロセスが大幅に省力化されます。Using containers, an application is deployed using self-contained packages that include any software, dependencies, and files needed to run the application, which greatly simplifies the deployment process.

また、アプリケーションとその基盤となるオペレーティング システムとの間に抽象化レイヤーが形成され、環境間の一貫性が確保されます。Containers also create an abstraction layer between the application and the underlying operating system, which provides consistency across environments. また、この抽象化によって、ホスト上で実行されている他のプロセスやアプリケーションからコンテナーを分離することができます。This abstraction can also isolate a container from other processes or applications running on a host.

回復性と自己復旧機能を実装する。Implement resiliency and self-healing. 回復性は、障害から回復するアプリケーションの能力です。Resiliency is the ability of an application to recover from failures. 回復性の方法には、たとえば一時的なエラーの再試行やセカンダリ インスタンス (場合によっては別のリージョン) へのフェールオーバーがあります。Strategies for resiliency include retrying transient failures, and failing over to a secondary instance or even another region. 詳細については、「Designing reliable Azure applications」 (信頼性の高い Azure アプリケーションの設計) を参照してください。For more information, see Designing reliable Azure applications . 問題を即座に把握して機能停止などのシステム障害に対処できるよう、アプリケーションをインストルメント化しましょう。Instrument your applications so that issues are reported immediately and you can manage outages or other system failures.

運用マニュアルを用意する。Have an operations manual. 運用マニュアルまたは "運用指示書" は、運用スタッフがシステムを保守するために必要な手順や管理情報を文書化したものです。An operations manual or runbook documents the procedures and management information needed for operations staff to maintain a system. その他あらゆる運用シナリオが文書化されるほか、サービスの障害など、中断が生じたときに役に立つ軽減計画も文書化されます。Also document any operations scenarios and mitigation plans that might come into play during a failure or other disruption to your service. この文書を開発プロセスの段階で作成し、以後、最新の状態に保つようにします。Create this documentation during the development process, and keep it up to date afterwards. これは随時更新される文書であり、定期的な見直し、テスト、改善が必要となります。This is a living document, and should be reviewed, tested, and improved regularly.

文書が共有されることがきわめて重要となります。Shared documentation is critical. 各自が持つ知識を提供し、共有するようチーム メンバーに奨励してください。Encourage team members to contribute and share knowledge. チーム全員が文書にアクセスできることが必要です。The entire team should have access to documents. チームのメンバーのだれもが簡単に文書を更新できるようにしてください。Make it easy for anyone on the team to help keep documents updated.

オンコール手順を文書化する。Document on-call procedures. オンコールの職務、スケジュール、手順を確実に文書化し、すべてのチーム メンバーと共有します。Make sure on-call duties, schedules, and procedures are documented and shared to all team members. この情報は常に最新に保つようにしてください。Keep this information up-to-date at all times.

サードパーティの依存関係のエスカレーション手順を文書化する。Document escalation procedures for third-party dependencies. 直接制御できない外部のサードパーティ サービスにアプリケーションが依存している場合、機能停止への対応計画を立てる必要があります。If your application depends on external third-party services that you don't directly control, you must have a plan to deal with outages. 計画した軽減プロセスの文書を作成しましょう。Create documentation for your planned mitigation processes. サポートの連絡先とエスカレーション パスを含めるようにしてください。Include support contacts and escalation paths.

構成管理を使用する。Use configuration management. 構成の変更は、計画されていること、運用の視点から明確であること、そして記録されていることが大切です。Configuration changes should be planned, visible to operations, and recorded. これは、構成管理データベース、またはコードとしての構成のアプローチとして具現化することができます。This could take the form of a configuration management database, or a configuration-as-code approach. 実際に必要な構成が実施されていることを確かめるために、構成は定期的に監査する必要があります。Configuration should be audited regularly to ensure that what's expected is actually in place.

Azure サポート プランを取得し、そのプロセスを理解する。Get an Azure support plan and understand the process. Azure には、さまざまなサポート プランが用意されています。Azure offers a number of support plans. ニーズに適したプランを選び、その利用方法をチームの全員が確実に理解する必要があります。Determine the right plan for your needs, and make sure the entire team knows how to use it. チームのメンバーがプランについて細部まで理解し、サポート プロセスの具体的な流れや、Azure のサポート チケットを申請する方法を把握していることが大切です。Team members should understand the details of the plan, how the support process works, and how to open a support ticket with Azure. 大きなイベントが予測される場合は、サービス制限の引き上げを Azure サポートにご相談ください。If you are anticipating a high-scale event, Azure support can assist you with increasing your service limits. 詳細については、「Azure サポートに関する FAQ」を参照してください。For more information, see the Azure Support FAQs.

リソースへのアクセス権を付与する際は最小限の特権の原則に従う。Follow least-privilege principles when granting access to resources. リソースへのアクセス権は慎重に管理してください。Carefully manage access to resources. 既定では、リソースへのアクセス権がユーザーに対して明示的に付与されていない限り、アクセスは拒否されます。Access should be denied by default, unless a user is explicitly given access to a resource. ユーザーに付与するアクセス権は、各自のタスクを遂行するうえで必要な範囲に限定しましょう。Only grant a user access to what they need to complete their tasks. ユーザーのアクセス許可を追跡し、定期的にセキュリティ監査を実施してください。Track user permissions and perform regular security audits.

ロールベースのアクセス制御を使用する。Use role-based access control. リソースへのユーザー アカウントとアクセス権の割り当てを手動のプロセスで実施することは避けてください。Assigning user accounts and access to resources should not be a manual process. ロールベースのアクセス制御 (RBAC) を使用して、Azure Active Directory の ID とグループに基づいてアクセス権を付与します。Use role-based access control (RBAC) grant access based on Azure Active Directory identities and groups.

バグ追跡システムを使用して問題を追跡する。Use a bug tracking system to track issues. 適切な方法で問題を追跡しないと、すぐに見落としや重複する作業、別の問題につながります。Without a good way to track issues, it's easy to miss items, duplicate work, or introduce additional problems. 担当者どうしの略式のやり取りで、バグの状態を追跡することは避けてください。Don't rely on informal person-to-person communication to track the status of bugs. バグ追跡ツールを使って問題の詳細を記録し、それに対応するリソースを割り当て、進行状況や状態の監査証跡を残すようにしましょう。Use a bug tracking tool to record details about problems, assign resources to address them, and provide an audit trail of progress and status.

すべてのリソースを変更管理システムで管理する。Manage all resources in a change management system. DevOps プロセスの要素はどのようなものであれ、管理およびバージョン管理のシステムに追加することをお勧めします。それにより、変更の追跡と監査を容易に行えます。All aspects of your DevOps process should be included in a management and versioning system, so that changes can be easily tracked and audited. そのような要素としては、コード、インフラストラクチャ、構成、ドキュメント、スクリプトなどがあります。This includes code, infrastructure, configuration, documentation, and scripts. テスト/ビルド/レビュー プロセスの最初から最後まで、こうした種類のリソースをすべてコードとして扱います。Treat all these types of resources as code throughout the test/build/review process.

チェックリストを使用する。Use checklists. 運用チェックリストを作成してプロセスの遵守を徹底します。Create operations checklists to ensure processes are followed. 大きなマニュアルでは、どうしても見落としが生じます。遵守すべきチェックリストを用意することで、見過ごされがちな細かな部分にまで注意を喚起することができます。It's common to miss something in a large manual, and following a checklist can force attention to details that might otherwise be overlooked. チェックリストはメンテナンスしてください。タスクを自動化してプロセスを合理化する方法がないか、絶えず模索するようにしましょう。Maintain the checklists, and continually look for ways to automate tasks and streamline processes.

DevOps の詳細については、Visual Studio サイトにある「DevOps とは」を参照してください。For more about DevOps, see What is DevOps? on the Visual Studio site.