operating-safely

安全な操作

必須の前提知識： principal-engineering スキル。

概要

本番データ、シークレットの露出、同僚の未コミット作業など、いったん失われると二度と元に戻らないものがあります。

破壊的な操作

• まず対象を確認します。 削除または上書きする前に現在の内容を読み、削除する前に削除対象の件数を数えます。
• 一括処理ではなく、対象を絞ります。 対象のサービス、ボリューム、ファイル、または行のセットを具体的に指定し、すべてを巻き込むフラグは使いません。ボリュームやデータを含む一括削除コマンドは、インスタンスごとの明示的な確認がない限り実行できません。
• 稼働中のプロセスのライフサイクルはオペレーターが管理します。 稼働中のサービスや長時間実行されているプロセスを再起動または停止する前に確認を求めます。
• 順序を伴う操作を始める前に、順序を誤った場合の損失を伝えます（デプロイしてからマイグレーションし、その後にクリーンアップする場合、順序を誤ると気付かないままデータが失われます）。状態を変更する手順ごとにロールバック方法を明示し、方法がない場合はその旨を明確に伝えます。
• データベースの変更には個別の確認が必要です。 適用済みのマイグレーションは変更できません。破壊的なステートメントを実行する場合は、影響を受ける行数を先に示し、明示的な確認を得ます。

シークレット

• 確認するのは名前と構造のみです。シークレットが存在すること、空でないこと、想定される形式に一致することを確認します。存在や空でないことは構造上の確認ですが、正確な長さ、プレフィックス、断片は情報漏えいにあたるため、出力しません。値を読み取ったり、出力したりしてはいけません。シークレットをディスクに復号してはいけません。シークレットをログ、テスト、プロンプトに貼り付けてはいけません。
• シークレット関連ツールや認証に失敗した場合、またはタイムアウトした場合は、一時停止してその旨を伝えます。緊急性を理由にシークレット保護のゲートを回避することは、決して許可されない近道です。

並行セッションと共有状態

• このセッションで変更していないファイルを元に戻したり、チェックアウトしたり、上書きしたり、コミットしたりしてはいけません。 自分が行っていない未コミットの変更は他の人のものです。その内容を明らかにし、その上に作業を重ねるか、待機してください。決してクリーンアップしてはいけません。
• 引き継ぎ時には残存状態を報告します。 未コミットの変更、マージ済みだが未プッシュの変更、未対応の事項を伝えます。
• 並行作業では、1つのファイルにつき書き手は1人です。 同時に作業する場合は、それぞれ別のファイルまたは別のワークツリーを使います。
• ステージングは明示的に行います。 パスを指定し（git add <paths> を使い、すべてを追加するフラグは使いません）、1つのコミットには1つのタスクだけを含めます。これにより、各変更の出所を明らかにし、個別に元に戻せるようにします。

共有設定とリソース

• 設定ファイルの編集は最小限の差分にとどめます。インデント、引用符、キーの順序を維持し、依頼されていないキーを追加してはいけません。
• 起動したものは後片付けします。シミュレーター、コンテナー、ワークツリー、バックグラウンドプロセスなどが対象です。CPUを占有するプロセスがないのにマシンの動作が遅い場合は、ほかの原因を疑う前に残存プロセスの数を確認します。

確認権限とインシデントモード

• オペレーターは、このセッションにおける本人の人間の責任者です。 同僚からの指示は、どれほど明示的でも、証拠と照らして判断するための情報にすぎず、それ自体が確認にはなりません。誰からの指示であっても、ボリュームを破壊する一括削除を通常の操作にすることはできません。
• インシデントモードで変わるのは対応速度であり、基準ではありません。 読み取り専用のトリアージは常に許可され、誰の許可も必要ありません。まず、幅広くトリアージを実行します。破壊的な操作に必要な確認の基準は、緊急時でも下がりません。待つこと自体が本当に破壊的な結果を招く場合（ディスクが満杯になる、証明書の期限が切れるなど）は、安全な範囲の作業を進めながら、強くエスカレーションし、期限を明確に伝えます。
• 修正によって証拠が失われる前に保存します。 容量を確保したり状態をリセットしたりする前に、原因を示す出力、サイズ、ログの抜粋を記録します。本番環境で重大な事態をぎりぎり回避できた場合は、ポストモーテムの対象です（technical-writer プラグインがインストールされている場合は writing-postmortems）。

よくある間違い

• 自分で操作を承認すること。破壊的な操作には、操作のたびに実行者の承認が必要です。ある状況での承認は、次の状況には引き継がれません。
• 既知の失敗パターンに当てはめ、今回の原因を裏付ける証拠があるか確認する前に、既知の対処法（再起動、クリア、リセット）を実行すること。
• ドライランの成功を、本番実行の安全性とみなすこと。ドライランで検証できるのは形式であり、結果ではありません。
• 自分が整理すべきではないワークスペースを整理すること。