ssmonline #14に参加
ssmonline #14 - connpassの参加(視聴)メモです。
手順書に関しての話をしていました。
手順書の書き方
- 体言止めはやめる。動詞をちゃんと使う。
- 主語と目的語を省力しない。
- よほどの理由がある場合以外は絶対パスを利用する。
- → 普段やってる人がやると無意識に補完してたりするけど、絶対パスで書くのが正解と思いました。
- ダイイングメッセージ性のあるコマンドを使う。
- 設定ファイルの新規作成はヒアドキュメントで書く、変更は
sed -e
がおすすめ。 - → 手順の中で
vi
とかで直で修正してしまうの微妙ですよね、反省します。
- 設定ファイルの新規作成はヒアドキュメントで書く、変更は
- 可読性などを考えると
$()
を使うようにする。
参照する
「正しい」運用手順書を作る /20181106-ssmjp-operation-procedure - Speaker Deck
ShellのGoogleのコーディング規約は目を通す
styleguide | Style guides for Google-originated open-source projects
grepのオプションをうまく使う
- -A NUM で行の後も表示
- -B NUM で行の前も表示
- -C NUM で行の前後も表示
grepのオプションとか確認したことはありますが、使えそうにないと思いスルーしていたのだと思います。
IaCで幸せにならない
運用が続いていく前提で設計していないと、引き継いだ人が困る。
構築した人はできてもその後が大事。
どう構築したか、どうアップデートするつもりか残すこと。
CFnは変更に弱い、引継ぎ大変。
学習コスト高い、AWSの全サービスに対応しているわけではない。
参考:CloudFormationで管理されたシステムの変更でエラー連発した話 - Speaker Deck
CFnは実務で使ったことないのですが、引継ぎ大変はなんでも同じで前任者が学習して構築したものを、後任が無学習で理解できるほどやさしい世界になってしまうと私が仕事でできることは完全になくなってしまうと思ってしまった。
Infrastructure as Codeのつらみの原因を探れ 恐怖症による負のサイクルを断ち切る“予測可能性” - ログミーTech
これ読んでみよう