概要
年明けに転職に伴って自己紹介のLTをした。
その内容を一部抜粋して記載する。
主にどんなことをやってきたか記載した。
苦労したところとそれに対する取り組み
- 開発生産性の改善
- 負荷試験の改善
- 組織課題の改善
開発生産性改善
辛かったこと
- 作業の再現性が低い
- 属人化
- 作業状況が見えづらい
対策
ワークフローのコード化
このリポジトリはいつ誰がどのようにテスト・ビルド・デプロイするのかコードを見ればわかるようにコード化するビルド、テスト、デプロイ、リリース、負荷試験などは繰り返される事が確定しているので、初期段階で自動化する
CIテンプレート作成
- 各マイクロサービスはGitHub Template Repository
- reusable workflow
- GitLabはここらへん充実していた
- 各マイクロサービスはGitHub Template Repository
デプロイ通知
CodeDeploy+SNS+Lambda+Slack
ArgoCD Notificationsデプロイ、リリース、巻き戻し手順書作成およびモブ作業
手順を番号で示しどこまでやったか伝わるようにする 作ったあとはモブ作業して手順書を検証するリリース対応のChatOps化
AWSコンソール作業->ChatOps化で- 作業時間が1/4に
- ミスが起きづらいように
- 開発メンバーならでもリリースできるように
障害対応のChatOps化 playbook表示
- 新規メンバーでも何かしら動けるように
- 対応状況をオープンに
開発工程調整
プロジェクト初期にprdまでのパイプラインを整備することで後半で問題が起こるのを防止
まとめ
チームの開発生産性をあげるために
- 開発のフィードバックサイクルをいかに早くするか?
- 再現性が高いか?
- 持続可能か?
- 認知負荷をいかに低くするか？
を考えて開発する
負荷試験改善
辛かったこと
- 環境の起動に時間がかかる
- 結果の収集に時間がかかる
- モニタリングするものが多い
- 作業負荷が集中する EC2インスタンスにログインし、手動でLocust実行
対策
自動化
- ecs run-taskで実行
- 結果はS3に保存＆ローカルにDL
モブプロ・モブ作業
シナリオ作成のモブプロ
負荷試験モブ作業で他のメンバーも負荷試験できるように
段階的な負荷検証
- ツールの検証
CloudFront+S3 - アプリケーション
フレームワークの初期実装 実際のアプリケーション実装 - データストア
参考『Amazon Web Services負荷試験入門』
まとめ
- 負荷試験は定期的に行われるので自動化することを前提として開発する
- ドキュメンテーションやモブ作業などを通して知識を共有する
- アプリケーションが複雑になるとボトルネックの特定が困難になるので、問題を切り分ける
職能横断組織と機能別組織
職能横断組織...サービスの機能ごと 例）決済チーム、ログイン・会員登録チーム
機能別組織...職種ごと 例）フロントエンドチーム、バックエンドチーム
辛かったこと
- 取引コストの増加
責任と権限の不一致
困りごと
EC2たてるのに別チームに依頼(チケット発行)が必要 二週間後にEC2が出来上がる対策
チームの目的に合わせた権限付与 dev環境は開発チームに操作権限を付与 開発チームがTerraformを書いてインフラチームがレビュー困りごと
開発チームがアプリケーションエラーが出ていることに気づかない SREがアプリケーションエラーを見つけて報告(内容がわからない)対策
開発チームにモニタリングの習慣をつける 朝会で開発チームがアプリケーションログとAPMを確認する 開発チームにエラー通知
まとめ
チーム全体の開発速度を速くするために
- 開発チームが自律的に開発する
- 開発チームが自律的に開発できる体制を作る DevOps, (Embedded)SRE
組織デザイン、プロダクトの性質、プロダクトのフェーズ、によって最適解が変わってくる
プロダクト視点と専門的な視点は両方必要なので両方の強みを活かす
参考 『エンジニアリング組織論への招待』 『マイクロサービスアーキテクチャ』 『EffectiveDevOps』
まとめ
- チームの開発生産性を支えるような活動をやってきた
- 再現性の高い開発環境づくり
- 継続的に開発できるチームづくり
プラットフォームというプロダクトの特性上、開発期間は長い
ブログのまとめ
LTスライドを転記してみたら非常に読みづらかった。
今後も開発生産性とか、継続的に開発できるチームづくりは注力していきたい。
