ぼくは明日、昨日のじぶんに頼りたい

明日のためのメモです。

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のオプションをうまく使う

grep(1) manページ

grep -A, grep -B, grep -C

  • -A NUM で行の後も表示
  • -B NUM で行の前も表示
  • -C NUM で行の前後も表示

grepのオプションとか確認したことはありますが、使えそうにないと思いスルーしていたのだと思います。

IaCで幸せにならない

運用が続いていく前提で設計していないと、引き継いだ人が困る。
構築した人はできてもその後が大事。
どう構築したか、どうアップデートするつもりか残すこと。

CFnは変更に弱い、引継ぎ大変。
学習コスト高い、AWSの全サービスに対応しているわけではない。

参考:CloudFormationで管理されたシステムの変更でエラー連発した話 - Speaker Deck

CFnは実務で使ったことないのですが、引継ぎ大変はなんでも同じで前任者が学習して構築したものを、後任が無学習で理解できるほどやさしい世界になってしまうと私が仕事でできることは完全になくなってしまうと思ってしまった。

Infrastructure as Codeのつらみの原因を探れ 恐怖症による負のサイクルを断ち切る“予測可能性” - ログミーTech
これ読んでみよう