gistfile1.md

ヒューマンエラーを許容する

• 「きをつけよう」は意味ない
• 実装、プラクティス、プロセスに落とし込む

バグ、ミスオペの混入を防ぐ

• コードレビュー
• 二人で作業
• テストケース
• 検証期間取る

完全ではない

バックアップ? スタンバイ?

• バックアップを世代管理

• 本当にバックアップ取れてるか? の確認

• サイズ確認

• リストアテストは時間かかるとのこと

• 正常運用のフローがあってのバックアップ

• 例外を起こした時に用をなさない

• 例外が混入しやすい事例を考える

• 緊急作業

• メンテナンス

• アクティブとの分離

• そのバックアップ、リストアできますか?

危険なインタフェースを避ける

• 事故を起こしやすいインタフェースを避ける
• デフォルトの指定が ALL
• 1台適用のつもりが全台

# イメージはこんな感じね
DELETE * FROM accounts;

• 簡単に全台指定出来てしまうオプション

deploy.rb --server=all

でも一台ずつ指定は面倒ではある。悩ましい

• フラグやオプション反転間違い

deploy.rb --deploy --target=active_hosts

deploy.rb --delete --target=active_hosts

# マジックナンバー怖い 
# 0、1 どっちが何なの? 
deploy.rb --delete --status=1

安全なインターフェースを使う/実装する

• alias rm="mv"

--dry-run

• 適用する対象を事前に確認
• 例) rsync, puppet

期待するログを取れるかでの防止

対話型インタフェース

• デフォルトが No

rm -rf 1000 Servers!? Are you crazy!? [y/N]

打ち間違い防止

色をつける

• 危険な操作 => 赤色

誤認識防止

操作を限定する

• 任意のコマンドを注入できるインタフェースを採用しない
• 定型の作業をオプションつけてコマンド化

# exec yum install
deploy.rb --install kernel

---

段階適用

• 検証 -> バックアップ -> 本番

• 面倒でも段階を踏まなければ適用出来ないデプロイ方法を取る

• ex. 検証環境で事後テストを通過後にバックアップに適用できる

• 環境の分離

• 開発環境、ステージング、本番

• 一気に本番全台適用を避ける

• 対象サーバーをランダムピックアップ、時間を置いてから全台適用

• 監視、お問い合わせドリブン

• 失敗した際の痛みはある

ミスオペの被害を最小限に

• 権限分離

• rootは何でもやれ過ぎる

• sudo

• 処理に必要なデータだけ触れるように分離

• Webだけ

• メールだけ

• APIを挟むとか

• 並列化、高速化の罠

• 簡単/高速にデプロイできる!!!

• デプロイミス時の障害拡大速度も高

• 削除系の実行には時間/手間をかけさせる

• NOT 並列化、シリアライズ

• 遅い、いらいら => 利便性とのトレードオフ

遅延削除

• それは同期的に削除すべきデータなのか?

• 例) 退会アカウントの実データ => 容量が問題なければすぐに消さなくても ok

• ゴミ箱に移動 -> cron で削除

• ジョブとしてキューに入れる、後日削除

• ジョブの量を監視