- 初期の management
- 初期はマネジメントなんてなかった
- 各メンバーが課題見つけてそれぞれやってた
- 個人プレー
- チームではなかった
- マイルストーンには夢がいっぱい
- 開発社が基盤を使うためのサポートで時間が取られていた
- アジャイルを始めた
- 2週間でスプリント
- カンバン
- 50% は reactive, 50% は proactive の比率のビジュアル化
- チームで動いてる実感を得た
- アジャイルで対応できない問題も出てきた
- ベロシティをあげるよりも機能を ship することを大事にする
- 6 week release cycle
- サイクルを 6 週間で区切る
- リリースの中に Big Epic, Small Epic
- 1 つの Big Epic にリリースチーム, Small は全体で 1 つのリリースチーム
- 1 チーム 2 ~ 3人くらい
- リリースチームは与えられた Epic のみに集中する
- EM なりが他のタスクが割り込まないように守る
- リリースチームはまずとにかく Unkown を潰す
- Unkown を潰した段階でどれだけのものが出来上がるか
- On support team
- 基本開発者のサポートと緊急の要件に対応する
- 暇なときは技術負債直したり
- 6週間全部 on support
- Next
- issue base から vision base に
- 3年ぐらいのロードマップを元に
- 基盤チームの責任範囲
- Master と Node までは基盤チームが見る
- Master は GKE なのでマネージド
- Pod みたいなのは開発者が面倒を見る
- Work and Resouce metrics
- スループット (rps)
- Succsess (2xx の rate)
- Error (5xx の rate)
- パフォーマンス (90％ とか 95% タイルでレスポンスタイム)
- Top Level Health が上の4つ (Work)
- 壊れているのか動いているのかを教えてくれる
- Utilization (Disk)
- Saturation (Memory Swap)
- Errors (依存しているリソースの error)
- アベイラビリティ (DB)
- Low Level Health (Resource)
- まず Work のメトリクスから見る
- Kubernetes cluster の work metrics
- Redy pods
- ヘルスチェックが通っている Pod の数
- Unredy pods
- Deployment とかの単位でもメトリクスを見ている
- Pod が redy かどうかは必ずしも cluster が悪いわけではない
- 存在している Pod の 10% が Redy じゃなかったらアラートにしている
- それだけでは足りない
- Redy pods
- Master
- マネージドされているので基本気にしていない
- API Server のメトリクスのレスポンスだけとるようにしているが、どうしよもないので依存しないようにしている
- Node
- kubelet の runtime の error rate
- pull できない error 等必ずしも kubelet が悪いわけではないので全部のオペレーションを足して 1% のゆるいアラート
- kube-proxy 可視化してるけどアクティブに使えていない
- Addon
- kube-dns 見ているけどあんま信頼できない
- Datadog Agant の監視もしている
- Cluster の resource metrics
- node を群として捉えてた場合のメトリクス
- 個別の node に対してもメトリクス
- あんまりアラートを仕込んでいない
- 両方見ている
- kubelet