2020-02-27 1on1

1on1 memo

• 仕事の進め方について
  • 第三者の目線を"適宜"入れることにより、軌道修正を入れることが大事
    • ブレーキを自分でかけようとするとうまくかからないことが多い
  • チームとしての成果を第一に考える
    • 他者に合意を得られるかが重要
  • 新しいサービスの評価に関しては、明確に期限を切るべき
  • 事前準備をしっかりする
    • 公式ドキュメントの熟読
• 工数割合の目安
  • 設計50, 実装30, テスト20
  • 設計の比重が大きくなるのは真理
    • 運用プロセスが考慮されているか
      • 他の人が運用する時の分かりやすさ、分かりにくさに頭を巡らす
      • build 方法、release 手順等
    • 仕組みはシンプルか (綺麗にしたい)
      • SRE 本の 単純さ という章を読む
    • 拡張性は適切か
    • 今の運用、課題を明確にする

Site Reliability Engineering

9. 単純さ

• system の安定性と agility
  • production software は、安定性と agility (機敏性) をバランス良く調整する必要がある
  • 馴染みない領域に対し試行錯誤し完全に理解出来ないことを前提とした場合、coding に有効期限を設けることが有効である
  • 開発に 信頼性 を持たせることにより、coding, system の feature, performance という本来注目すべきことに集中出来る
  • Robert Muth: 探偵ものの物語とは違い、スリルやサスペンス、謎解きがないことこそ、ソースコードの望ましい姿なのです
  • 必要な複雑さと想定外の複雑さの区別を考えることが重要
    • 必要な複雑さ: ある状況が抱える取り除くことが出来ない本質的な複雑さ
    • 想定外の複雑さ: engineering によって解決出来る複雑さ
    • SRE は、受け持つ system に想定外の複雑さが生じた場合は差し戻しを行う
    • SRE は、運用する system から複雑さを取り除く努力を継続的に行う
• 行の削除と計測
  • エンジニアは自分の作成物に共感を抱くので差分に敏感だが、コメントアウトで残すより削除したほうが良い
    • 24/7 稼働する web service であれば、新しい code 1行が負債と言える
      • 潜在的な障害や bug の可能性を持つ
    • software bloat (肥大化) を避ける
      • feature の追加に伴い、software が大きく、低速になる傾向を指す言葉
• 最小限のAPI
  • 上手い設計は、分散 system において協力し合い、scope が明確ではっきりとした目的がある
    • util, misc といった binary を作成して production に deploy することは良くない
• release
  • 単一の変更のみの release をすべき
  • 機械学習における 勾配降下法 と比較出来る
    • 一度の step の変化が改善されているのか、劣化しているのかを検討し最適解を得る方法
• 結論
  • software を単純にすることは、信頼性を持たせる為の前提条件である
    • ある task を各 step で単純化する方法を考える時、本当に実現したいこととそれを最も簡単に行う方法を明確化しようとし、怠けることをしない