データなリリース手順を考える

ちょっと殴り書きぽいですが。。。

チェックリストをした時はどうしてもどんなテストをしたか？みたいなところに思考が行ってしまうので、自分なりに要素分解して考えてみることにした。

大きなリリース時（今までとは利用方法が変わるような）は考えてみるといいと思う点をあげてみる。

チェックリストは、大丈夫なことを確認するのではなくて、「あれ、ワシコレちゃんとやったっけ？」が気付ける資料であるべきだと思う。

### リリースをするにはを考えみた時に、行動はMECEにな状態にしたい
リリースに関する作業はいづれかに入ってくるハズ
作業者視点
作業者以外視点
データそのものの視点

### 作業者視点を要素分解してみる
開発
テスト
影響範囲調査

### 作業者以外視点を要素分解してみる
影響システム
連絡（いつどこで、どんなことがおこなわれるのかk？）
経過観察（何やってるかわからないと辛い）
作業者もエンジニアと、そうでない人に分けられるきもしてきた
エンジニアでない人向けに、影響するデータを明記する。

### データそのものの視点

実行時は、瞬間的にデータが見えなくなるなどの影響はあるのか(overwriteなど)？
オペレーショナルメタデータの更新はあるのか？
フォーマットが変わるのか。

### あとはコレらを時系列で見るとどうか

たとえば、リリースの一時間後、1日後、2日後にデータは、作業者は、作業者以外はどうなってるべきなのか
リリースの一時間前 　　
当日は時間が作れるよじょうたいか？とか

### ひとまず事前準備におけるチェックリストを作ってみる

- 当日、翌日の体制は決まっている
- 作業担当はペア作業になっている
- 確認に利用するアカウントは決まっているか？
- 影響範囲は洗い出せているか？
- 他のシステム利用者とのインターフェースが明らかである
- ヒントとして、データはどうなるのか？、システムはどうなるのか？
- 自分のシステムに変更のある場所
- ヒントとして、データはどうなるのか？、システムはどうなるのか？
- 当日作業のタスクの作業時間がわかっているか？
- リハーサルが行われている？
- 当日作業のタスクの洗い出しは全て終わっている
- リリース後の確認手順は4つ分けられているか
　- システムが動作しているか？
- リリース直後の確認/リリース後の確認(1h~)/リリース後の確認(翌日〜)が確認項目として含まれているか？
- 影響範囲に対するテストが全て含まれているか？
- 切り戻しの手順が明らかになっている
- ヒントとしてどのデータに影響があって、ダメだった場合はどこを再実行すればいいのかわかっている
- 切り戻しの時間が明らかになっているか？
- 複雑な手順やSQL等はスクリプト化されているか
- バックアップを取得しているか(不要なら不要な理由を記載)
- 作業にチェックポイントを定めているか
- チェックポイントごとに確認ができるとベター
- リリースの続行および中止の判断基準を定めているか
- 単体テストは完了しているか
- ステージングでの確認は完了しているか。
- ここでいわゆるテスト項目のチェックがはいる。
- 関係者への周知が完了しているか？
- 関係の遠い人と（非エンジニア）、近い人と連絡を分けているか(エンジニア)？

### うむ。

あとは、コレらを垂直に考えて。。

水平にも考えて。。。

こう考えると、チェックリストの一環としてリリースの連絡のフォーマットもある程度決まってくる気がするな。

チェックリストだけでも、考えると深い。。