blog2017-02-16作業手順書を書くときに気をつけたいこと最近社内で手順書をレビューしてて気になったことがあったので、書いておく。作業の目的を明確にするまず、なんのための作業なのか明確にしておく必要がある。管理者を追加したいデータをクリーニングしたいリリース作業したいなど作業の目的は様々であるが、それがはっきりしないことには、そもそも手順が正しいかどうか判断できない。「今度削除するデータをお客様の要望により念のためバックアップしたいです。「はい、でも対象になるデータは、n週間前のデータなので週次バッチでバックアップが残っていると思います。「確かにそうですね」みたいな不毛なことがないようにしたい。日本語の表現を曖昧にしない例えば履歴のデータをクリーニングするとする。口語でサラッと書いてしまうと境界条件が曖昧になってしまう。SQL見れば自明だろ!って思うかもしれないけど、日本語とSQLとどっちが正しいか確信が持てない。スコープを揃えるスコープと言う表現が適切ではないかもしれないが。先の例でいうと、履歴データは年月日のデータを持っているので、「先月まで」「半年」みたいな月や年単位の表現ではなく、日をベースに範囲とかを記述すべきだと思う。‘2017-02-01’;と書いてもらえると、SQLと日本語で違いがない。日本語の表現としては少し変な感じがするかもしれない。境界条件はハッキリしたい。時刻は固定された表現にするついでに書くと「先月」という表現は作業をする時点で変わってしまう。2月だと1月だし、6月だと5月になってしまう。作業をする時点での、明確な時刻を指定した方が揺るぎがないので、極力時刻を固定した方が良いと思う。作業が延期されたりすることもあるが、その際にはその時の日時で手順書を更新すべきだと思う。後から振り返ったときに、いつやった作業なのか明確になっている方が良い。「2017-02-01データクリーニング手順書.txt」となっていても、実際には3月に作業したみたいなこともあって、そういう時にファイル名も更新すべきだし、手順書の内容もちゃんと日時を合わせるべき。根拠を明確にする手順書に落とし込む必要はないかもしれないが、作業の根拠は明確でないといけない。「データクリーニングの対象レコードが1億件あるので、メモリが足りない可能性があります。「前回2千万件のレコード削除の際にはメモリが枯渇していました。レコード数が同じだった時にCOPYはダメでpg_dumpは大丈夫という根拠が明確でないといけない。同じ操作ではないのでもちろんリソースの使い方も違うと思うし、一方が良くて一方が良くないという理由はちゃんと説明できないといけない。そもそもどちらの作業も考慮が足りてなかったんじゃないか?と思ってしまう。影響がなかっただけで。実際、何が影響して障害になったりするかわからない部分も正直あるんだけど、少なくとも自分がやる作業については、どういう作業でどういう影響があって、どういうリスクを伴うかというのは根拠を持ってないといけない。根拠が間違っているかもしれないんだけど、そこが揺らぐと何もできないし、自分で説明できるレベルで根拠はしっかりしておいてほしい。他にもあった気がするけど、とりあえず終わり。Local(Amazon公式)のDockerイメージを使う先日の8月22日に、Amazonから公式にDynamoDBのDockerイメージが...2018-08-31iPhone/Macで使えるMarkdownエディタを検討するブログの執筆を前提にしたエディタを評価してみた。modへ移行する2018年振り返りと2019年やりたいこと月別アーカイブはてなブログをはじめよう!kentaro_kawanoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。