このリストの基礎は、上流のコンテナランタイムチーム（podman、buildah、skopeoなど）の自動化をサポートした複数年の経験です。これらのヒントの多くは、進化した経験とユーザーと開発者の大規模なコミュニティからの個々の貢献の融合に基づいているため、私は完全に信用しません。
以下のほとんどの項目は、1つの原則に要約できます。複雑さを排除または軽減する 。この概念は、マーフィーの法則の複合アプリケーションに基づいています。 ：「壊れやすいもの」が多いほど、マーフィーが現れる可能性が高くなります。これらの偶然の遭遇を回避する8つの方法があります。
[読者も気に入りました：新しいAnsibleAutomationHubの紹介]
1。ネットワークの依存関係を減らす
ネットワークの依存関係を減らします。特に、制御できないサードパーティのサービスを減らします。さらに、ファーストパーティおよびセカンドパーティのネットワークサービスは、「可能であれば回避する」と見なす必要があります。この推奨事項には、実際には2つの側面があります。
- あらゆる観点から、ネットワーキングは関連するコンポーネントとリアルタイムの関係の非常に複雑なシステムです。一般的に言って、これらはすべて、一方の端からもう一方の端までほぼ完璧に動作する必要があります。そうしないと、悪い日になる可能性があります。
- 繰り返しになりますが、大まかに言えば、ネットワーク障害は一時的で時間に依存することがよくあります（誰もがそれらを迅速に修正することを望んでいます）。これにより、事後デバッグが非常に困難になる可能性があります。大量のログを記録しても、観察されない影響が悪い日を始める可能性があります。
2。ソフトウェアの依存関係を減らす
可能であれば、特にサードパーティのライブラリでのソフトウェアの依存関係を減らしてください。これには、コア自動化サブジェクトと共有自動化コードの両方が含まれます。スタックの上下にあるすべてのコンポーネントをバージョンロックしない限り、予期しない動作やAPIの変更によって破損するリスクがあります。含まれているコードを制御すると状況は少し良くなりますが、それでもリスクがあります。
注 ：このヒントはかなり物議を醸す可能性があり、多くの状況で確かに意味がないことを認めます。特に、ライブラリに1つの単純な関数を導入したい場合は、「よく考えてください」というリマインダーと考えてください。
3。自動化ジョブを手配する
失敗の結果の降順で自動化ジョブを配置します。言い換えれば、マイナスの影響が最も大きいアイテムをできるだけ早くキャッチするようにしてください。ここでの考え方は、影響が大きく、検出コストが低い「フープシー」のリソース（時間を含む）を節約することです。 VCS継続的インテグレーション（CI）テストの例：
- サードパーティのネットワークサービスにアクセスできますか？たとえば、pingを実行して、SSL証明書を検証できますか？
- ベンダーまたは含まれているコードは、文書化および構成された要件のリストと実際に一致していますか？
- 誰かが誤って新しくコミットされたコードに「FIXME」コメントを残しましたか？
- すべての新しいコミットは署名されていますか？
- 変更は実行コンテキストと一致しますか。たとえば、リリーステスト中の文書化されていない変更や、コード変更による文書化/テスト更新の欠落などです。
時間の経過とともに、このワークフローの効果は、重要なチェックが最も注意を払い、最も信頼性の高いメンテナンスを受けることです（障害は列車全体を停滞させる傾向があるため）。同様に、開発者はより速く循環することもできます。たとえば、自分の名前のつづりを間違えたことがわかるだけで、長い間待つことはありません。
4。仕事を短くする
仕事をできるだけ短くし、簡単に繰り返すことができる「チャンク」にしてください。これは主にオーケストレーションソフトウェアに依存しますが、ほとんどのアプリでは複数の実行段階が可能です。別のCIテストの例を使用して、ユニットテスト、統合テスト、およびシステムテストを（この順序で）実行する場合は、単一のスクリプトでそれらをすべて一緒に次々に実行することは避けてください。このように、統合ステップが失敗した場合でも、ユーザーは単体テストを再実行する必要はありません。これにより、冗長な操作を再実行せず、マーフィーを自動化ギアトレインに不必要に招待することで、信頼性が向上します。
5。実行時に必須ではない操作を避ける
実行時に必須ではない操作（インストールや構成など）は避けてください。代わりに、事前に必要なすべてのビットを使用して実行環境を準備してください。これにより、物事がより効率的に実行されるだけでなく、この記事の他のヒントに従うのにも役立ちます。また、ビルド時に事前に構築された環境を観察およびテストすることもできます。環境がいくつかの異なる要件を持つジョブ間で共有されている場合は、それらのコンポーネント/パッケージをイメージ内にキャッシュすることを検討してください。実行時にローカルキャッシュからインストールする方が、ネットワーク経由でリモートリポジトリにアクセスするよりもはるかに安全で信頼性が高くなります。
6。適切なツールを使用する
手元のタスクに使用できる最も基本的なツールを使用します。たとえば、ビットマスクを適用した後にバイナリフラグを検証する必要がある場合は、bashスクリプトでこれを実行しようとしないでください。同様に、C ++プログラムが一連のコマンドを実行するだけの場合は、代わりにbashを使用してください。これにより、ジョブの主な目的とは関係のない副作用に操作がさらされないため、信頼性が向上します。
7。障害の追跡
シグニチャの頻度に基づいて障害を追跡します。ほとんどの場合（すべてではありません）、自動化に失敗すると、どこかにログに記録される兆候が発生します。これらを識別して分類し（たとえば、リクエスト名で）、発生の集中記録を保持できるようにします。おそらく、これを実現するにはかなりの作業が必要であり、複数のサービスやAPIを学習してインターフェースする必要があるかもしれません。ただし、署名の頻度でソートされた結果を使用すると、どの問題が最も多くの人に影響を与えているかをすばやく見つけることができます。これらのアイテムは最も注意を払う必要があり、自動化の信頼性に最大の影響を与えます。
8。コメントを効果的に使用する
コメント理由 方法ではありません 。コードの読者なら誰でも、コードの機能を判断できると仮定します。彼らはあなたがコードを書いたときにあなた（作者）が何を考えていたかを判断することはできません。自動化には多くの可動部品が含まれます。一部の関係は、初心者の読者には明らかでない場合があります。コメントは、コンポーネントの関係について通知するときに特に役立ちます。
たとえば、次のコメントについて考えてみます。
# Default variable value comes from CI unless executed manually.
# Detect this (`$CI == false`) to ensure the user did not leave
# the value blank. これが飾るコード、つまり変数の定義または検証の形式を簡単に想像する必要があります。さらに、追加の情報ソース「CI」（スクリプトのコンテキストで意味するものは何でも）を示唆しました。
このような役立つコメントは、スクリプトのすべての行を飾る必要はありません。それらをターゲットにします。外部ファイルまたは力（太陽フレアを含む）の影響を受けるアイテムに焦点を当てます。これらの詳細により、「秘密のソース」が将来の機能強化やメンテナンスを担当するすべての人に継続的に渡されるようになるため、自動化の信頼性が高まります。
[Red Hatの無料ガイド：ビジネスを自動化するための5つのステップ。 ]
まとめ
ほとんどの場合、これらすべてのヒントに従うことは不可能です。これらは、代替の実装が合理的である場合の妥協のガイドラインとして機能することを目的としています。そうでなければ、利害関係者に最善のサービスを提供するために、これらの原則のいくつかに違反することが必要になる場合があります。それでも、他の人（良いコメントを書くなど）は、時間の経過とともに微妙ですが着実な効果をもたらす傾向があります。私は、物事を単純に行うことは、ダクトテープを叩くよりもはるかに難しいことが多いことを最初に認めます。ただし、時間が経つと、ほとんどのダクトテープは乾いて無愛想になり、問題を再修正する必要があります。将来の自分に有利に働き、最初からシンプルさを目指してリファクタリングに時間を費やしてください。