DevOpsのテキスト研修
DevOpsのデプロイメントパイプラインをどう保護するか
これまで学んだ原則に沿って、DevOpsチームと共にIT組織の継続的デリバリーを支えるパイプラインを作ったら、外部の承認なしで低リスクな本番デプロイができます。本番デプロイの大半で変更承認プロセスを経る必要がなくなります。外部の承認者だけに頼る代わりに、適切に設計したソフトウェアデリバリーの方法、テストと監視の自動化、環境の状況に応じたアラートを頼りにするからです。セキュリティとコンプライアンスは、引き続きDevOpsチームの重要な責任です。法令上の要件を満たすためだけでなく、顧客をしっかり守るためでもあります。組織内のセキュリティとコンプライアンスの専門家に助言を求め、協力することは続けます。そのうえで、自社が事業を行う法制度に準拠した安全なシステムを設計することを、日々の業務と習慣にします。
本番システムに対する変更の種類
- 標準変更 リスクが低く、承認が不要で、完全に自動化され、記録されるため、すばやくデプロイできる変更です。たとえば、データベースの参照テーブルの更新、コンテンツの更新、スタイルの変更、OS、データベース、その他の外部コンポーネントに対する標準的なパッチです。
- 通常変更 リスクが高く、変更諮問委員会（CAB）の承認が必要です。CABは、変更を評価するために変更要求書（RFC）の提出を求めます。CABのメンバーは変更を評価するのに十分な知識を持たないことが多く、長いリードタイムが必要です。変更を保留し、最終的には経験、直感、そして誰が変更を求めたかについての先入観に基づいて判断します。
- 緊急変更 リスクが高く、上級管理職の承認が必要です。顧客に影響する本番システムの重大なエラー、問題が起きたデプロイの修正、セキュリティパッチ、サービスの復旧などが該当します。
変更の種類にかかわらず、DevOpsチームは、RemedyやJiraなどの変更管理・作業計画システムにすべての変更を記録し、チーム内外の全員が作業を把握できるようにします。
自動デプロイの成功実績を使い、通常変更を標準変更に移行する
通常変更に対する標準変更の割合を高めてこそ、変更諮問委員会（CAB）の承認を省き、作業の流れを速め、デプロイメントパイプラインの品質を高められます。
自動デプロイの成功実績を使い、できるだけ多くの通常変更を標準変更へ移行します。CABにデプロイの実績と本番環境のインシデント一覧を示し、自動化した本番デプロイでインシデントが発生していないか、発生しても影響がごく小さいことを実証します。
通常変更のデプロイを速める
通常変更として残す必要があるものは、変更要求書（RFC）の作成を自動化します。自動テストと手動テストの全結果、解決済みと未解決のインシデント、監視記録、本番以外のシステムのログをRFCにひも付けます。CABの仕事を簡素にし、CABが求めるすべての情報を最初の版に入れ、承認をできる限り早めます。
承認後は、通常変更をワンクリックでデプロイできるようにします。通常変更の種類をCABと定期的に見直し、どのような条件を満たせば通常変更を標準変更へ移行できるかを洗い出して定義します。これにより、DevOps組織の変更の大半を自動でデプロイできるようになります。
DevOps組織の官僚的な手続きと他者への依存を減らす
組織が大きくなるほど、官僚的な手続きが増えやすくなります。官僚主義には、目に見えないところで指数関数的に膨らみ、いつまでも続く性質があります。自分の仕事の承認を一つ上の権限者や管理機構に頼ると、自分に権限があり、仕事の結果に責任を持つという意識が薄れます。その結果、一つ上の権限者も繰り返し判断を誤ります。
やがてその権限者も別の権限者に頼り、監査を受けるようになります。この悪循環は、次の組織再編まで続きます。再編後は、ほぼ100%の確率で、形を少し変えた別の悪循環が、今の悪循環に取って代わります。
職務分離やチーム外の権限と管理の仕組みに頼ると、ソフトウェアデリバリーが遅れ、品質が下がるだけでなく、組織の安全性まで損なわれることを忘れてはいけません。米国の大手金融機関では、開発者がATMソフトウェアにバックドアを仕込んだため、ATM不正の被害に遭いました。外部の監査担当者、セキュリティ専門家、コンプライアンス担当者、CABの権限者のいずれも、本番環境にデプロイされた不正なソースコードを発見できませんでした。この不正を発見できたのは、コードを開発したチーム内で、チェックインしたコードの検査やコードレビューなど、DevOpsの基本的な手法を使った場合だけです。
迅速かつ安全に届けるには、他者への依存と職務分離を減らす必要があります。どちらも、DevOpsチームが自ら責任を取る妨げになるからです。代わりに、チェックインしたコードの検査、ペアプログラミング、ピアレビュー、自動テスト、監視などの仕組みをチーム内で使います。法的に職務分離が必須の場合でも、DevOpsチームに組み込んだ統制により、監査担当者やコンプライアンス担当者は、よりよい情報に基づいて、より適切かつ迅速に判断できます。
まとめ
DevOpsは、コンプライアンスと情報セキュリティに、新しく動的な側面をもたらします。インフラがコードで定義され、コードによってシステムが作られたり消えたりし、コードが自動でデプロイされる環境では、実際に何が起きているかを監査担当者が理解するのは簡単ではありません。新たな課題であると同時に、無駄が少なく効果的な監査とコンプライアンスの仕組みを整え、担当者が力を発揮できるようにする機会でもあります。
情報セキュリティ、コンプライアンス、デプロイメントパイプラインの高速化は、DevOpsチーム全員の仕事です。チームの重要な目標の一つは、コンプライアンス担当者が、チームのデリバリー品質を裏づける情報、ログ、報告書、指標にセルフサービスでアクセスできるようにすることです。これにより、煩雑な承認手続きを簡素化し、場合によっては完全に省けます。
