8.5 テストとプロセスの自動化
概要と動機
テストとプロセスの自動化とは、反復的な手作業のエンジニアリングと運用の仕事を、信頼できる、機械が実行するワークフローに置き換える実践です。テストの側では、これはテスト自動化を意味します。正しさ、パフォーマンス、セキュリティを検証するために継続的に走る、自動化されたテストスイート。プロセスの側では、ソフトウェアのデリバリーと運用を取り巻く仕組みに広がります。コンプライアンスの証拠の収集、運用のランブックの実行、既知の問題の是正、ガバナンス、セキュリティ、コストの統制の徹底。統一する考えは単純です。繰り返し予測可能に行われることはすべて体系化し、一貫して、素早く、人間の苦役なしに走るようにする。
大きなチームにとって、自動化は、品質と統制が規模のもとで崩れるのを防ぐ唯一の方法です。手作業のテストは、数百人のエンジニアが行う数千の変更に追いつけません。それはボトルネックになり、そのカバレッジは一貫せず信頼できなくなります。手作業の運用手順も苦しみます。サービスの再起動、資格情報のローテーション、監査の証拠の収集は、疲れた人間が大きな資産群にわたって圧力のもとで行うと、遅く間違いやすくなります。この仕事を自動化することは、結果を再現可能にします。また、熟練したエンジニアを、本当に人間の洞察を要する、判断の重い問題に集中させます。
企業と政府の文脈では、自動化は、コンプライアンスを持続可能にする鍵でもあります。規制対象の組織は、統制が整っていて証拠が収集されていることを、継続的に示さなければなりません。これを手でやることは、高価で、遅く、隙間を生みがちです。証拠の収集と統制の徹底を自動化することは、コンプライアンスを、定期的な大慌てから、システムの継続的で検証可能な性質に変えます。この「コンプライアンス・アズ・コード」のアプローチは、コストを下げ、監査人と規制当局が求める保証を強めます。
主要原則
- 繰り返され、予測可能で、ルールベースの仕事を自動化し、人間の労力は判断のために取っておきます。
- 自動化されたテストを速く、信頼でき、決定論的にします。さもなければ無視されます。
- テストを並列で走らせ、早く行い、スイートが育ってもフィードバックを速く保ちます。
- 運用手順を、バージョン管理され、テスト可能で、実行可能になるよう、ランブック・アズ・コードとして体系化します。
- システムに外から取り付ける脆いスクリプトより、よく統合された自動化を好みます。
- コンプライアンスの証拠を、通常のワークフローの副産物として自動的に生成します。
- 高リスクの行動には人間を介在させ続けます。まず安全で日常的なものを自動化します。
推奨事項
速く、信頼でき、並列のテストインフラストラクチャを築く
テストスイートは、エンジニアがそれを信頼し、それが素早くフィードバックを返す場合にだけ価値があります。スイートを多くのワーカーにわたって並列で走らせるテストインフラストラクチャに投資し、テストの数が数千に育っても全体の経過時間が低く保たれるようにします。スイートをピラミッドとして構造化します。多くの速いユニットテスト、より少ない統合テスト、少数のエンドツーエンドのテスト。そうすればフィードバックの大半は数秒で届きます。不安定なテストを容赦なく排除してください。断続的に失敗するテストは、エンジニアに失敗を無視するよう訓練するので、テストがないより悪い。統合とエンドツーエンドのテストが、現実的で隔離されたインフラストラクチャに対して走るよう、一時的でオンデマンドのテスト環境を提供します。
リリース、コンプライアンス、証拠収集を自動化する
自動化をテストを超えて、リリースとコンプライアンスのワークフローに広げます。監査人が必要とする成果物をパイプラインに自動的に生成させます。誰が変更を承認したかの記録、どのテストが走って通ったか、セキュリティスキャンが何を見つけたか、まさにどの成果物がデプロイされたか。統制をコードとして扱い、必須のチェックが一様に徹底され、その結果が記録されるようにします。この「コンプライアンス・アズ・コード」は、証拠の収集を、監査の前の手作業の大慌てから、継続的で常に最新の記録に変えます。またそれは、システムのコンプライアンスの姿勢を、どの瞬間にも観察可能にします。
ChatOpsとランブック・アズ・コードを採用する
運用手順を、古くなる散文の文書ではなく、バージョン管理に保たれた実行可能なランブックとして体系化します。手順が安全でよく理解されている所では、オンデマンドで実行できる自動化に配線します。ChatOpsは、これらの運用を共有のチャットインターフェースに持ち込むので、オペレーターは、透明で協調的で記録される会話の中で、自動化された行動を起動し観察します。これは運用をチーム全体に見えるようにし、何が行われたかの自動的な記録を作ります。また、自動化が正しい手順を符号化しているので、経験の浅いエンジニアが手順を安全に実行する障壁を下げます。
自動化された是正を慎重に実装する
よく理解された繰り返し起こる問題には、条件を検知して既知の修正を適用する自動化された是正を築きます。失敗したプロセスの再起動、負荷のもとでのスケールアップ、満杯のディスクのクリア、コンポーネントのフェイルオーバーなど。低リスクで確信の高い是正から始めます。影響範囲の大きいものには、人間の確認を要求します。自動化された是正は、平均復旧時間を減らし、繰り返しのアラート疲れをなくします。しかしそれは確かな検知の上に築かなければならず、安全装置を含めなければなりません。誤ったシグナルに基づいて動く自動化は、インシデントを増幅しうるからです。オペレーターが完全な可視性を保って介入できるよう、自動化されたすべての行動を記録します。
ロボティック・プロセス・オートメーション(RPA)を正しく位置づける
ロボティック・プロセス・オートメーションは、人間が行うクリックとキー入力を模倣して、既存のユーザーインターフェースとアプリケーションを駆動し、タスクを自動化します。RPAには、APIを公開せず他の方法では統合できないレガシーあるいはサードパーティのシステムへの橋として、正当な居場所があります。そうしたケースには実用的に使いますが、限界を知ってください。UI駆動の自動化は本質的に脆く、インターフェースが変わるたびに壊れ、統合の根本的な欠如には対処しません。適切なAPIや統合が利用できる所では、それを好みます。RPAを、戦略的な基盤ではなく戦術的なつなぎとして扱い、システムが近代化されるにつれて置き換える計画を立てます。
ガバナンス、セキュリティ、コストの統制を自動化する
組織の統制を、継続的に走る自動化されたチェックとして符号化します。インフラストラクチャのガードレールのためのポリシー・アズ・コード、パイプラインでの自動化されたセキュリティスキャン、コストの異常と遊んでいるリソースの自動検知。ガバナンスの自動化は、統制を一様で迂回不能にし、手作業のレビューが決してカバーできない変更の量にスケールします。セキュリティ方針を徹底するのと同じアプローチが、暴走するクラウドの請求書や、欠けた必須のタグに旗を立てられます。ガバナンスは、定期的な手作業の監査から、継続的な自動化されたガードレールに移ります。
トレードオフ: 長所と短所
| 選択 | 長所 | 短所 | 最適な場合 |
|---|---|---|---|
| 幅広い自動化されたテスト | 速く一貫したフィードバック。変更を可能にする | 構築と保守のコスト。不安定さのリスク | 規模のすべてのチーム |
| コンプライアンス・アズ・コード | 継続的で監査に即応できる証拠 | 統制を体系化する前もってのエンジニアリング | 規制対象の組織 |
| ランブック・アズ・コード + ChatOps | 再現可能、可視、記録される運用 | 体系化して保守する労力 | 本物の運用負荷のあるチーム |
| 自動化された是正 | より速い回復。少ない苦役 | 検知が間違っているとリスク | よく理解された繰り返しの問題 |
| RPA(UIの自動化) | APIのないシステムをつなぐ | 脆い。統合の隙間を覆い隠す | つなぎとしてのレガシーシステム |
| 自動化されたガバナンス | 一様で迂回不能な統制 | ポリシーの作成と調整の労力 | 大きく統治される資産群 |
中心的なトレードオフは、前もっての投資対継続的な苦役とリスクです。自動化は、構築と保守に常に労力がかかります。不安定なテスト、脆いRPA、悪いシグナルで起動される是正のように、まずく築かれた自動化は、信頼を侵食したり失敗を増幅したりするので、ないよりも悪くなりえます。規律は三重です。本当に繰り返し可能で信頼できるものを自動化し、その自動化を信頼できるものにすることに投資し、判断や高いリスクが求める所では人間を介在させ続ける。うまく行えば、自動化は何倍にも元を取ります。不注意に行えば、それ自体が負債になります。
チームで議論すべき問い
統合とエンドツーエンドのテストは、現実的で一時的な環境に対して走りますか。それとも全員が奪い合う共有のステージングの箱に対してですか。 プルリクエストごとのオンデマンドの隔離された環境は、チームが互いを妨げたり共有の状態を汚したりせずに、統合とエンドツーエンドのテストが現実的なインフラストラクチャを使えるようにします。単一の共有ステージング環境は、より多くのチームが積み重なるにつれて、ボトルネックと、不安定で順序依存の失敗の源になります。一時的な環境を立ち上げられるか、そのコストはいくらか、どのテストが本当にそれを必要とし、どれが速いインメモリの代用品で足りるかを決めてください。データを持ち込んでください。ステージングがどれだけ頻繁に競合するか、いくつの失敗が共有環境の干渉にたどれるか、統合の層の現在の経過時間。答えは、テストの信頼性と、ピラミッドの上の層がどれだけ速くフィードバックを返すかの両方を形づくります。
運用手順は、ランブック・アズ・コードとして体系化されChatOpsを通じて提示されていますか。それとも、古くなる散文のままですか。 体系化されバージョン管理されたランブックはテスト可能で実行可能であり、共有のチャットインターフェースを通じて走らせることは、すべての行動を可視にして自動的に記録します。それは、自動化が部族の記憶に頼らず正しい手順を符号化しているので、経験の浅いオンコールのエンジニアが安全に行動する障壁を下げます。どの手順が最初に配線するのに十分安全でよく理解されているか、人間が介入できる状態をどう保つかを決めてください。大きな資産群では、この透明性は、誰がいつ何をしたかの監査記録を兼ねます。現在のランブックを持ち込み、どれが古いかに注意し、最初に体系化する、最も実行される二つか三つの手順を特定してください。
パイプラインで、どのセキュリティスキャンとポリシーのチェックがマージをブロックし、どれが警告するだけですか。 自動化されたガバナンスは、統制が迂回不能である場合にだけ築く価値があります。警告するだけのチェックは、wikiの方針とまったく同じく、期限の圧力のもとで無視されるからです。統制ごとに、何がブロックして何が警告するかを決めてください。重大な脆弱性や欠けた暗号化のタグはおそらくブロックし、低い重大度のスタイルの指摘は警告かもしれません。規模では、これが、手作業のレビューが決してカバーできない変更の量にわたって、セキュリティとコストのガードレールを一様に徹底する方法です。現在のチェックの目録を持ち込み、それぞれをブロックか助言的かに印を付け、それから誤検知率を議論してください。うるさいブロックのチェックは、人々に例外を要求するよう訓練するからです。ブロックと警告の線が、ガバナンスが歯を持つか持たないかの分かれ目です。
人間が先に確認しなくても動かせる自動化された是正はどれで、検知が間違っていた場合の影響範囲は何ですか。 自動化された是正は回復時間とアラート疲れを削りますが、誤ったシグナルで起動される修正は、小さな揺らぎを完全な停止に変えうるので、何が無人で走るかの決定は、便利さではなくリスクの決定です。相反する引力を量ってください。無人の行動は最速ですが最もリスクが高く、人間が介在する確認はより安全ですが、取り除こうとした遅延と苦役を再導入します。候補の是正を、頻度と最悪の影響範囲で順位づけたもの、それぞれの背後の検知の過去の誤検知率、すべての行動が記録され元に戻せるかを持ち込んでください。大きな企業あるいは政府の資産群では、本番のデータや市民向けのサービスに触れるものには、正式な変更権限とロールバックの計画を加えてください。監査も元に戻すこともできない自動是正は、規制当局があなたに止めさせるものだからです。
自動化が負債に朽ちないよう、その保守の資金と所有をどう割り当てますか。 テスト、ランブック、ポリシーのチェック、RPAのボットはすべて、周りのシステムが変わるにつれて腐り、放置された自動化はないよりも悪いです。古いランブックは危機で誤った自信を与え、壊れたRPAのボットは静かに仕事を落とします。緊張は、保守が同じエンジニアをめぐって機能の仕事と競合し、何かが壊れるまで見えないので、期限の圧力のもとで最初に削られることです。自動化の資産の現在の目録、不安定なテストと壊れたボットの積み残し、すでに維持に使われているエンジニアの時間と予算の誠実な見積もりを持ち込んでください。企業あるいは政府の設定では、各重要な自動化について説明責任のある所有者を名指しし、保守の資金を明示的な項目として出してください。保守されない統制が静かに失敗したとき、誰が責任を負っていたかを、監査人とインシデントのレビューが尋ねるからです。
RPAで自動化するレガシーシステムごとに、そのRPAを本物の統合に置き換えて退役させる具体的な計画と引き金は何ですか。 RPAはAPIを公開しないシステムへの正当な橋ですが、出口の計画のない橋は、静かに恒久的で脆いインフラストラクチャへと固まり、UIが変わるたびに壊れ、それがつなぐはずだった統合の隙間そのものを根づかせます。トレードオフは本物です。RPAは今すぐ速く安く価値を届け、適切なAPIの統合は前もってより高くつきますが耐久性があるので、規律は、RPAを購入ではなく、期日のある借入として扱うことです。本番のRPAのボットの一覧、それぞれが依存するシステム、それぞれがどれだけ頻繁に壊れるか、根底のシステムのために近代化あるいは統合の取り組みが実際に資金を得てスケジュールされているかを持ち込んでください。何十年も前の中核アプリケーションを抱える企業と政府の資産群では、各RPAのボットを、名指しされた近代化のマイルストーンに結びつけてください。退役の日付なしに静かに重要になったRPAは、それがスクレイピングするインターフェースが変わり続ける年ごとに複合する技術的負債だからです。
セクター別の視点
スタートアップ。 2、3人のエンジニアでインフラストラクチャを築く時間がないなら、すべての変更で数分で走る小さく速いテストピラミッドを保ち、不安定なテストは、その週に直すか削除する本物のバグとして扱ってください。まだ必要のない重いコンプライアンスのツールとポリシー・アズ・コードは飛ばし、最も実行される二つか三つの運用上の修正だけを、チャットから起動される単純なスクリプトとして体系化します。日々の苦役を取り除くものを自動化し、ガバナンスの問題を抱える前にガバナンスの仕組みを築くことには抵抗してください。
小規模事業者。 専任のテストあるいはプラットフォームの専門家がいないので、オーダーメイドのテストインフラストラクチャを築くのではなく、すでに払っているツールに組み込まれた自動化に頼ってください。CIサービスの組み込みのテストランナー、そのスキャンのアドオン、マネージドな環境。築くか買うかの選択を、現実的に維持できる保守を軸に枠づけてください。誰も保守できない巧妙なカスタムのパイプラインは、より素朴なホスト型のものより悪い結果だからです。RPAは控えめに、他の方法では統合できないシステムをベンダーのツールがつなぐ所でだけ使います。
大企業。 多くのチームにわたる目標は、手作業のレビューがカバーできない規模での、一様で迂回不能な統制です。一時的な環境を伴う共有の並列テストインフラストラクチャ、ポリシー・アズ・コードのガードレール、すべてのパイプラインの実行から自動的に生成されるコンプライアンスの証拠。各チームが脆いスクリプトを再発明するのではなく、是正とランブックのツールを再利用するよう、インターフェースを標準化し、自動化を、明確な保守予算を持つ、所有され資金のあるポートフォリオとして管理します。あるチームで警告するだけのチェックが、別のチームではブロックとして扱われないよう注意してください。一貫しない徹底は、あなたが払っている保証を損なうからです。
政府。 調達規則、透明性の義務、継続的な監視の義務づけが、コンプライアンス・アズ・コードをほぼ不可欠にします。すべてのパイプラインの実行は、チェックされた統制、行われたスキャン、与えられた承認を、改ざんが明らかで監査に即応できる証拠として記録すべきです。将来の契約が別の供給者に移れるよう、独自のロックインより、オープンで可搬な自動化を好み、市民向けのサービスに触れる是正には、責任を負う人間を保ちます。何十年も前のシステムがRPAを強いる所では、それを、公的な近代化の計画を伴う、意図した一時的な橋として文書化し、ガバナンスのチェックを、すべての変更で義務づけられたセキュリティの基準線に保ちます。
事例
スタートアップ。 7人のスタートアップは、ほとんどが速いユニットテストと少数の統合テストからなる、無駄のないテストピラミッドを保ち、すべてが並列で走るので、完全なスイートがプルリクエストごとに3分未満で終わります。テストが不安定になり始めると、本物のバグとして扱い、その週に直すか削除します。小さなチームでは、無視された一つの赤いビルドがスイート全体への信頼を侵食するからです。また、最も一般的な二つの運用上の修正、詰まったワーカーの再起動と満杯のディスクのクリアを、Slackから起動される小さなスクリプトとして体系化するので、オンコールの誰もが、それを書いた一人のエンジニアを呼び出さずに安全に実行できます。
大企業。 大手のeコマース企業は、数万のテストのスイートを、ワーカーのフリートにわたって並列化して動かし、完全なスイートが数分で完了します。現実的な統合テストのために、プルリクエストごとに一時的な環境が立ち上がります。運用はChatOpsを通じて走ります。オンコールのエンジニアがチャットから体系化されたランブックを起動し、過負荷のサービスのような一般的な失敗は自動的に是正され、レビューのためにその行動が記録されます。パイプラインがセキュリティスキャンと承認の証拠を自動的に収集するので、年次の監査は、手作業の証拠探しではなく、常に最新の記録に頼ります。
政府。 厳格な継続的監視の要件に従う公的機関は、コンプライアンス・アズ・コードを実装します。すべてのパイプラインの実行が、チェックされた統制、行われたスキャン、与えられた承認を記録し、要求に応じて監査人を満足させる、改ざんが明らかな証拠を生みます。中核のシステムの一つがAPIを持たない何十年も前のアプリケーションなので、機関は、近代化の取り組みが進む間、そこへのデータ入力を自動化する意図した橋としてRPAを使い、適切な統合ができたらRPAを退役させる明示的な計画を持ちます。自動化されたガバナンスのチェックが、すべてのインフラストラクチャの変更で、義務づけられたセキュリティの基準線を徹底します。
ビジネスケース: 動機、ROI、TCO
テストとプロセスの自動化のROIは、取り戻されたエンジニアの時間、より速く安全なデリバリー、より速いインシデントからの回復、劇的に低いコンプライアンスのコストとして現れます。自動化されたテストは、デリバリーの性能を支える、素早く自信ある変更を可能にします。自動化された運用と是正は、チームと予算を消耗させる苦役と停止時間を削ります。コンプライアンス・アズ・コードは、監査を、数週間の手作業の準備から日常的なクエリに変ええて、それは財務的にも評判の面でも節約です。
TCOの比較は、自動化を築いて保守する本物の継続的なコストを、自動化しないコストと量ります。手作業のテストと運用は、費やされた時間だけがコストなのではありません。すり抜ける欠陥、長引くインシデント、専門の職員を消費する監査、反復的な苦役をするエンジニアの燃え尽きもコストです。リーダーシップには、論拠は率直です。自動化は、繰り返される運用費用とリスクを、スケールする、一度きり加えて保守の投資に変え、品質とコンプライアンスを、散発的ではなく継続的にします。一つの注意を率直に述べる価値があります。自動化は保守され信頼されなければなりません。資金のない放置された自動化は、負債へと朽ちます。
アンチパターンと落とし穴
- 容認された不安定なテスト。 断続的な失敗は信頼を破壊し、エンジニアに赤い結果を無視するよう訓練すること。
- 壊れたプロセスの自動化。 悪いワークフローを自動化すると、散らかりがより速く起こるだけ。まずプロセスを直すこと。
- 戦略としてのRPA。 脆いUIの自動化を恒久的な解決として頼ることは、統合の隙間を覆い隠して根づかせること。
- 確かな検知なしの是正。 悪いシグナルで起動される自動化された修正は、インシデントを増幅しうること。
- 古い散文としてのランブック。 古くなった文書に住む手順は、危機で誤った自信を与えること。
- 手作業で集めるコンプライアンスの証拠。 定期的な手作業の証拠探しは高価で、監査の間に隙間を残すこと。
- 高リスクの行動に人間がいない。 危険な操作の完全な自動化は、災難を防ぐ判断を取り除くこと。
成熟度モデル
レベル1: 開始。 テストと運用は、おおむね手作業で反応的です。カバレッジはその場しのぎで、手順は人々の頭の中か古い文書にあり、是正はインシデントの間に手で行われ、コンプライアンスの証拠は各監査の前に慌てて組み立てられます。
レベル2: 発展。 自動化されたテストは存在しますが、遅い、不安定、あるいは一貫せずに走り、実践はチーム間で大きく異なります。いくつかの運用スクリプトとランブックが局所的に存在しますが、是正は依然として手作業で、ガバナンスは継続的なチェックではなく定期的なレビューで徹底されます。
レベル3: 標準化。 速く、並列で、信頼できるテストインフラストラクチャが、文書化された組織全体の標準です。ランブック・アズ・コードとChatOpsが一般に使われ、コンプライアンスの証拠はパイプラインの実行から自動的に生成され、ガバナンスの統制は、チーム間で一貫して適用される、徹底された自動化されたチェックとして走ります。
レベル4: 管理。 自動化自体が、ベースラインに対して測定され制御されます。不安定なテストの率、スイートの経過時間、自動是正されたインシデントの平均復旧時間、自動化された証拠を持つ統制の割合、ブロックするチェックの誤検知率を追跡し、各指標を合意された目標に保ちます。是正とカバレッジの決定はこのデータに駆動され、すべての自動化された行動が記録されるので、傾向と退行は推測されるのではなく見えます。
レベル5: オーケストレーション。 自動化は継続的に改善され、組織全体に統合されています。自動化された是正は、実証された安全装置とともに日常のインシデントを扱い、コンプライアンスは継続的で常に監査に即応でき、テスト、運用、ガバナンスのツールチェーンはシステムが変わるにつれて適応し、RPAの橋は統合が成熟するにつれて積極的に退役されます。人間は判断に集中し、機械は繰り返し可能なものを扱い、システム全体は証拠に基づいて再均衡します。
議論のためのアイデア
- どの運用手順は完全に自動化しても安全で、どれは人間を介在させ続けなければなりませんか。
- 大きなテストスイートが育つにつれて、どう速く不安定さのない状態に保ちますか。
- あなたのレガシーシステムで、RPAが正当化される橋はどこで、それを退役させる計画は何ですか。
- どの統制を、最初に手作業の監査から継続的なコンプライアンス・アズ・コードに変換できますか。
- インシデントの増幅のリスクを負わずに、自動化された是正への信頼をどう築きますか。
- 自動化が負債に朽ちないよう、それが必要とする継続的な保守の資金をどう出しますか。
要点
- 繰り返され、予測可能で、ルールベースのものを自動化し、人間の労力は判断と高リスクの決定のために取っておきます。
- 自動化されたテストを速く、並列で、信頼できるものにし、不安定さを容赦なく排除します。
- 運用をランブック・アズ・コードとして体系化し、可視性と記録のためにChatOpsを通じて提示します。
- 監査が継続的で最新の記録に頼れるよう、コンプライアンスの証拠を自動的に生成します。
- RPAは、APIのないシステムへの意図した一時的な橋としてのみ使い、その退役を計画します。
- ガバナンス、セキュリティ、コストの統制を、継続的な自動化されたチェックとして徹底し、危険な行動は人間が監督します。
参考文献とさらなる読み物
- Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams.
- Jez Humble and David Farley, Continuous Delivery.
- Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering (see the chapter on eliminating toil).
- Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
- Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
- NIST Special Publication 800-53 and 800-137 (continuous monitoring).
- Open Policy Agent documentation (policy as code).