# Mercari Meetup for Microservices Platform #2

* [connpass](https://connpass.com/event/128017/)

## How we structure our work at Microservices platform team @deeeet

* 初期の 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年ぐらいのロードマップを元に

## Monitoring Kubernetes cluster @spesnova

* 基盤チームの責任範囲
  * 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 じゃなかったらアラートにしている
  * それだけでは足りない
* 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