保守におけるデータ修正の手順書のテンプレート
こんにちは。深緑です。
年度末ですね。
年度末はお客様の方もバタバタしているせいか、
イレギュラーなことが起きて仕方なくデータ修正を依頼されることが増えてきます。
バタバタしてきて危険な予感がしてきたので、今回データ修正の手順書を整備してみました。
前提
- 本記事ではタスクはチケットで管理されているとします。
- データベースはMySQLとします。
- データ修正作業はある程度パターン化されているとします。
手順書のテンプレート
データ修正においては、修正のパターンごとにテンプレートを用意し、
以下のサイクルで作業を進めます。
- 作業が発生したらテンプレートをコピーして、今回の修正に必要な手順書を作成。
- 手順書をレビュー。
- 手順に従って修正作業を実施。
- 修正後は実行結果を貼り付け、保存。
- 作業中に気づいた点があれば、テンプレートを修正。
もしテンプレートが存在しない修正作業が発生した場合は、
既存のテンプレートをベースに今回分の手順書を作成し、
修正作業後に実行履歴から新たなテンプレートを作成するようにします。
# 概要
* 対象チケット:(ここにチケットのURLを貼り付けてください)
* 作成者:(ここに作成者の名前を記述してください)
* 作成日:yyyy/mm/dd
* 確認者:(ここに手順書の内容を確認した人の名前を記述してください)
* 確認日:yyyy/mm/dd
# 作業前の確認事項
- [ ] 修正前の状態を確認するSQLが用意されているか?
- [ ] 修正SQLのWHERE句に誤りはないか?
- [ ] 修正後の状態を確認するSQLが用意されているか?
# SQL
## トランザクション開始
```
BEGIN;
```
## 修正前確認SQL
対象のプロセスが実行中のままであることを確認。
```
SELECT * FROM batch_processes WHERE id = ??? AND status = 1;
```
## 修正SQL
ステータスを異常終了に更新。
```
UPDATE batch_processes SET status = 9 WHERE id = ??? AND status = 1;
```
## 修正後確認SQL
ステータスが異常終了になってることを確認。
```
SELECT * FROM batch_processes WHERE id = ??? AND STATUS = 9;
```
## トランザクション終了
※確認SQLの結果が想定通りの時のみ実行。
```
COMMIT;
```
# SQL実行結果
```
(ここにSQLの実行結果を貼り付けてください。)
```
# 作業後の確認事項
- [ ] 修正前の状態を確認するSQLを実行しているか?
- [ ] 修正前の状態は想定通りか?
- [ ] 修正後の状態を確認するSQLを実行しているか?
- [ ] 修正後の状態は想定通りか?
手順書のテンプレートをテキストで作成する理由
テンプレートを作っている目的は、常に最新の手順に従って作業を行うことです。
テンプレートを作る前は過去の実行履歴をコピーして手順を作るような運用になっていました。
その頃は、コピー元に古いものを選んでしまうと最新の手順に沿ってないということが起きていました。
テンプレートをテキスト形式にしてるのは以下の理由です。
- OSの機能で検索可能にする。
- ExcelだとSQLをセルからコピペした時改行が入ってしまい、コピペした瞬間実行されてしまい少々危険。
- (やろうと思えば)Gitで管理できるようにする。
テンプレートにトランザクションを書いておく
私の周りでは修正のSQLそのものは皆しっかり書かれるのですが、トランザクションはあんまり意識が向かないようです。
トランザクションなしでいきなりデータ修正するのは怖い運用なので、
テンプレートの方で書いておくようにしました。
各SQLのWHERE句には更新対象のカラムを含める
各SQLのWHERE句にはできるだけ更新対象のカラムを含めるようにしています。
これにより「値」だけでなく、「件数」で状態を確認できるようにしています。
チケットにはせずあえてテキストファイルで管理する
手順書をBacklogなどのチケット管理システムに登録することも考えましたが、セキュリティ上の問題から見送りました。
修正SQLやその実行結果には個人情報が含まれることがあるので、WEBにあげるのはよろしくないと思います。
従って、テンプレートとそこからできた手順書はファイルで社内サーバーに保存しておくようにしています。
ワークフローもあえて回していない
テキストファイルなのでGit管理して、何ならプルリク使ったレビューもできなくはないのですが、
これもセキュリティの観点からGitにあげること自体よくないだろうと思い見送っています。
最後に
データをSQLで直接更新するのは本来よくないんですが、まあありますよね・・・。
現実を受け入れつつせめて少しでも安全に回していくため日々改善に取り組んでいこうと思います。
Discussion