はじめに
新人2年目SREエンジニアの孤軍奮闘備忘録。
監視基盤・運用基盤のクラスタ配置をどうするかという題目で仕様書を作成するときに感じた内容。
とにかく、以下の内容をもとに新人はドキュメント作成を進めるべし。
前提
とあるクラウドとオンプレ環境それぞれにkubernetesクラスタが混在する環境でのコンポーネント管理をどうするかという検討資料を作成することになった。
コンポーネントとは
・ArgoCD
・認証基盤（secret managerとか
・監視基盤（Grafana Lokiとか
新しく管理用クラスタを構築する？
AWS/オンプレミスどちらで管理する？
それを決めて欲しいとのこと
我、とにかくドキュメント作成を進めたせいで手戻りが鬼発生
我、とにかくドキュメント作成を進める。
しかし、以下の事態が発生。
そもそも前提条件違くね？
「これ書く必要ないですよ。決まってることなので、前提から考え直した方がいいですね」
まぁ、このPJがクライアントからの返信ないと進められないような内容を仮で決めて進めている影響もあるが、そもそもの前提条件をしっかりと先輩方と握っていなかったのが悪い。
前提条件や確定事項を整理してからタスクを進めないと手戻り発生するので、そこをチーム内で整理した上でドキュメントを作成した方がいい。
そもそもこのタスクの目的とゴール違くね？
「このタスクって〇〇が目的なので、ここまで考えなくていいですよ」
目的もすり合わせるべき。
Aさんの考えていたタスクの目的と我の考えていたタスクの目的があっていなかった場合、無駄な箇所または不足箇所が発生してしまう可能性がある。
構成考えなおした方がいいかも
タスクの目的とか前提を揃えないまま書き始めたから、構成もおかしなことになってた。
しかも、目的とか前提とか揃えた上で構成を練り直してもワシのハードスキルではとんちんかんな構成になっていたりしたので、再度修正が発生。
ドキュメント作成の方針
以下の流れで進めると綺麗になる。
- タスク概要と目的を合致させてチーム内で合意をとる
- ドキュメントの前提・構成を1の内容およびPJの進行状況などから導き出す。このときの抽象度は高くする
- 抽象度の高い状態でタスク概要・目的・前提・構成の合意をチーム内でとったら、更に具体性を出して構成だけ完成させてチーム内で合意をとる
- 具体的に中身を書き始める
①タスク概要と目的を合致させてチーム内で合意をとる
まず、タスク概要と目的がない状態でドキュメンテンショーンを進めても絶対にどこかでこける。
概要と目的がない状態ではゴールが見つからない状態で砂漠を歩いているのと同じである。
②ドキュメントの前提・構成を1の内容およびPJの進行状況などから導き出す。このときの抽象度は高くする
概要と目的が決まれば、次は前提条件。
前提条件がなければ不足箇所や無駄な箇所が生まれる。
例えば、お客さんがセキュリティ最優先なら、それベースで意思決定を下すことができるが、その前提条件がなければ0からその思考を我々で生み出さなければならない。
そこで構成を書き始める。
目的と前提があれば、必要な要素が決まるため構成が決まる。
③抽象度の高い状態でタスク概要・目的・前提・構成の合意をチーム内でとったら、更に具体性を出して構成だけ完成させてチーム内で合意をとる
構成を決めたからといって、書き始めてはいけない。
チーム内で合意を取り、さらにその粒度をあげていく。
演繹的に徐々に合意を取り進めることで、手戻りの発生を抑える。
④具体的に中身を書き始める
ここでようやく具体的なハード的な中身を書いていく。
例えば、ArgoCDの導入方法なら、コマンドとかコードとか運用法とか。
中身を書いている段階でも疑問があれば、チーム内で投げていく。
自分を信じてはいけない。
さいごに
参考なったらLIKEしてね。
やっぱり、アウトプットしないと身に付かんね。