2022/04/21_DevOpsDays Tokyo 2022での、西村の講演資料になります
Airワーク採用管理での改善活動とDevOpsへの歩み2022年4月21日株式会社リクルート 西村祐樹
View Slide
自己紹介西村祐樹所属株式会社リクルート部署プロダクト統括本部 プロダクト開発統括室プロダクトディベロップメント室 ＨＲ領域プロダクトディベロップメントユニットＨＲ領域エンジニアリング部 ＨＲアーキテクトグループちょうど3ヶ月前にも弊社の改善事例についてお話させていただきましたhttps://speakerdeck.com/recruitengineers/tech-meetup2-nishimuraアーキテクトが考えるシステム改善を継続するための心得
・システムの安定稼働、開発を維持するために構造的な問題を解決して 価値を発揮する・技術の精通だけでなく、現場の課題認識と解決能力も求められる (いわゆるシステム設計だけにとどまらない)・主に古くからある大規模システムを担当している (古くからある大規模システム ≒ ビジネス規模の大きいシステム)我々の組織の役割私の主な担当システム
『Airワーク採用管理』について2018年にリリースされたサービス採用HP, 求人掲載, 採用管理などを手軽にできる採用活動を支援するためのサービスになります本日はこの『Airワーク採用管理』(以降『Airワーク』で統一します)のシステム改善に関わる中で見えてきたDevOpsについての考え方について紹介していきます
4~6月 7~9月 10~12月 1~2月第1章利用拡大に向けた改善実施第2章チーム分析とDevOpsの実践第3章自立と連携への歩み出し2021年 2022年
第1章利用拡大に向けた改善実施
『Airワーク』の利用拡大が事業の注力ポイントとなる2021年4月 2022年4月約2倍！アカウント数目標イメージ昨年4月に『Airワーク』の利用拡大方針が打ち出され、アカウント数を始めとする目標値及びそれに向けた案件が動き出していった2021年4月『Airワーク』の利用拡大していくぞ！
事業方針に伴い我々も『Airワーク』に関わるこっちも見ながらこれまでサービス規模的に深く携わっていなかったが事業方針転換に伴い注力対象とすることにこちらにも注力我々の動きの変化New!アーキテクトT
全体構成概要についてnode group(CL用)node group(CS用)VPCk8sクラスタWebバッチ兼用Web用CI/CDシステム(ConcourseCI)ECRGithub Enterprise社内NWSESLambdaAurora PostgresElastiCacheモニタリングS3
まずは利用拡大に伴い起こることを整理し現状把握を進める利用拡大によって何が起きるかを整理し「システム負荷」「品質劣化」「運用負荷」それぞれの懸念の深刻度合いを見ていくことにした利用拡大に伴い何が起こる？アカウント数増える案件増えるアカウントに紐づくデータが増えるアクセスが増えるコードの変更が増える機能が増えるWeb, DBサーバ負荷増加バッチ処理時間増加Webレスポンス劣化コードの複雑度増加変更による障害率増加 品質劣化懸念システム負荷懸念デプロイ手順, 時間増加テスト環境枯渇開発者/並走案件が増える運用負荷懸念
node group(CL用)node group(CS用)VPCk8sクラスタWebバッチ兼用Web用CI/CDシステム(ConcourseCI)ECRGithub Enterprise社内NWSESLambdaAurora PostgresElastiCacheモニタリングS3システム負荷懸念について利用拡大による懸念ポイントは？起きることとしてはこの2つアクセスが増えるここが増えるデータ量も増える
node group(CL用)node group(CS用)VPCk8sクラスタWebバッチ兼用Web用CI/CDシステム(ConcourseCI)ECRGithub Enterprise社内NWSESLambdaAurora PostgresElastiCacheモニタリングS3システム負荷懸念について利用拡大による懸念ポイントは？発生する懸念としてはこれらがあるストレージ不足性能劣化CPU負荷増加メモリ不足バッチ実行時間増加メモリ不足メモリ不足送信数上限同時実行上限
システム負荷懸念についてそれぞれの対策についてEC2, ElastiCache, RDSともにスケールアップという手段はあるもののスケールキューブの考え方をベースに他の対策案も検討X軸: 水平スケール(例: インスタンスを追加)Y軸: 機能軸で分離(例: 更新, 参照でアクセス先DBインスタンスを分ける、機能軸でデータも分離する )Z軸: シャーディング(例: アカウントIDの偶数、奇数で格納インスタンスを分ける )X軸Y軸Z軸X軸 Y軸 Z軸Web インスタンス追加 機能ごとのさらなる分離(マイクロサービス化 )-バッチ(実行時間) 並列処理化 - -ElastiCache - 機能ごとにインスタンスを分け クラスタ構成&シャーディングRDS スケールアウト(Readレプリカのみ)読み込み専用機能は Readレプリカを使うインスタンス分けSES, Lambda - - マルチリージョン化ケアすべき箇所と対策案を整理して利用拡大に備えることに
システム負荷懸念についてちゃんと現状把握できる？Datadogである程度は見れる
node group(CL用)node group(CS用)VPCk8sクラスタWebバッチ兼用Web用CI/CDシステム(ConcourseCI)ECRGithub Enterprise社内NWSESLambdaAurora PostgresElastiCacheモニタリングS3システム負荷懸念について必要な項目見れてる？RDSのメトリクスも見れるEC2のメトリクスは見れるElastiCacheは一部取得していないものあり5xx, 4xxエラー頻度は見れるがレスポンス時間は未取得バウンス率は見れるが送信数は未取得処理時間など未取得やや不足気味なので必要な項目は追加すべきと認識
システム負荷懸念についてモニタリング、アラートは？負荷高騰時はSlackや電話通知がくる
システム負荷懸念についてアラート検知時の対応は？影響ないほうって必要？落ち着いたので静観しますサービス影響ない場合サービス影響出た場合集まって対応だ！既知の問題なので静観します
システム負荷懸念について・検知はするけど特に何もしないもの例: 負荷の高いバッチが実行されたことによりCPU負荷が一時的に高騰した・検知して調査はするものサービス影響ない場合 ★こっちが9割くらい締めてる例: エラーログが出ているが対応中だったり、対応優先度低としているもの極力なくすべきまたは別の指標に置き換えるべき頻出したら優先度上げて減らすようにすべきサービス影響出た場合・突発的な問題により回避が難しいもの・事前対策で回避できた可能性があるものどうしようもないので発生都度対応と自動復旧の仕組み化などをしていくべしシステムモニタリングによる傾向分析などの予防活動をしておくべき例: 突発的なサーバ障害、マネージド機能障害例: アクセス増加でDB負荷が高まりCPU100%張り付きモニタリングしていても活用についてアップデートが追いついていないと認識
システム負荷懸念についてその他そもそも参画時点でRDSのCPU負荷が高かかったのでスロークエリを抽出して対応瞬間的に100%近くまで上がることもあった対応後はCPUも落ち着き利用拡大に伴い徐々に上がっているが充分に耐えれている状況
システム負荷懸念について結論、システム負荷懸念に対しては以下の2軸でいくことに1. 利用拡大に向けた対策案の整理(短期)・スケールアップ、スケールアウトの実現性は？・発動させる条件は？2. 運用含めたモニタリング強化(長期)・不足している情報は追加する・モニタリングの活用(運用)についても整理する
品質劣化懸念について障害傾向(変更失敗率が増加傾向になってないか？)既存ソースコード分析(客観的に見通しのよい状態か？)計画外作業(手戻りが多くなってないか？)手戻りを中心に各工程の実体を確認しようとしたが未計測だったので保留特定の主要機能についてやや失敗率が高め (週1回リリースで2~3ヶ月に1回頻度 ≒ 約10~20%)フロントエンド ↔ BFF ↔ APIという構造でフロントエンドと BFF周りのコードが複雑になっていた障害分析, 計画外作業に加えてコード自体も一通り確認
結論、品質劣化懸念については最低限のケアで凌ぐことに1. 既存アーキテクチャの見直し発生など高難度な案件がきた際にはレビューで対応2. 変更失敗率が高くなってきたら別途見直す品質劣化懸念について
デプロイ手順は？運用負荷懸念についてnode group(CL用)node group(CS用)VPCk8sクラスタWebバッチ兼用Web用CI/CDシステム(ConcourseCI)ECRGithub Enterprise社内NW①コード取得②イメージビルド③イメージ登録④k8s applyすでにCI/CDの仕組みはありデプロイ手順自体に大きな課題はなし
デプロイ時間は？運用負荷懸念についてnode group(CL用)node group(CS用)VPCk8sクラスタWebバッチ兼用Web用CI/CDシステム(ConcourseCI)ECRGithub Enterprise社内NW①コード取得②イメージビルド③イメージ登録④k8s applyここが約1時間かかるサービス立ち上げ当初よりも徐々に伸びている毎回リリース当日にイメージビルドを実施していたため時間がかかりつつあった
デプロイ時間は？運用負荷懸念についてスキーマ変更を伴うリリースではメンテナンスリリースを実施しており、深夜作業も発生今後の機能追加に伴い時間が伸びる懸念があったため事前ビルド方式が必要と判断メンテナンスモード切り替えビルド&イメージ登録デプロイ内部動作確認DBマイグレーションメンテナンスモード切り替え03:00 05:00ここだけで1時間メンテナンスモード切り替えデプロイ内部動作確認DBマイグレーションメンテナンスモード切り替え03:00 04:00こうできるはず※ビルド&イメージ登録は前日に済ませる
運用負荷懸念についてテスト環境は足りる？案件案件案件案件テスト環境1テスト環境2大型案件A大型案件B案件C案件D案件E確認待ちor 一時的に環境拝借テスト環境としては2つあるが、人員、案件の増加に伴い足りなくなる恐れがあった企画、開発者の人数増 案件増ここで詰まる開発フローや運用負荷に影響
運用負荷懸念についてテスト環境は足りる？案件案件案件案件テスト環境1テスト環境2大型案件A大型案件Bシンプルに増築することも可能だったが、インフラ作業のリードタイムがかかるのと今後の拡張性を見据えてテスト用のEKS環境を用意することに企画、開発者の人数増 案件増EKSC用環境D用環境E用環境案件C案件D案件Eブランチごとに環境を複製できる仕組みを構築過去にタウンワークで実施したノウハウを転用
結論、運用負荷懸念については直近効果ありそうな以下の2点を実施することに1. デプロイ手順の改良によりリリース時間短縮2. テスト環境拡張による開発フロー、運用負荷の改善運用負荷懸念について
開発T対応優先度を決めて各チームと連携アーキ側で各対応についてのハンドリングをして徐々に進めていくスタイルを実施アーキテクトTインフラT1.システム負荷モニタリング項目追加スケール対策検討アラート見直し2.運用負荷デプロイ改善テスト環境拡張3.品質劣化設計/コードレビュー..その他発生ベースで適宜優先度判断具体案検討タスク化適宜対応依頼
結果、利用拡大に伴う各懸念についてのBefore, After4月から活動開始し7月頃には概ね対応が落ち着くめでたしめでたし！と言いたいところだったが。。。システム負荷懸念品質劣化懸念運用負荷懸念利用拡大に伴う各主スケール案不足モニタリングすべき項目不足アラートの形骸化、予防活動不足スケール案整備各種項目追加と可視化完了アラート見直し、モニタリング体制の確立クリティカルな品質低下要因は見つからず高難度な案件についてレビューする体制を構築デプロイ時間増加に伴う深夜作業負荷平行案件増加に伴うテスト環境不足デプロイ改善に伴う作業時間削減テスト環境拡張で動作確認効率化Before After
参画前後の認識差異システム面での改善はしたものの、現場の課題認識や対応不足が浮き彫りになった。我々ががっつりサポートしなくても大丈夫な状態にできないのか？そもそもなぜこのような状態になっているのか？を考えてみることにした。参画する前はこう考えてた 開発T: 現状こういう状態で、利用拡大に伴ってやばくなりそうな箇所はここです → 現場に課題認識があり技術難度の高いところを中心にフォロー実際はこうだった 開発T: 利用拡大に伴いどうなるかわからない、、 サーバリソースのどこに響くのかとかよくわからない、、 → 現場での現状整理ができておらずここから実施が必要 → 直近の対策はできたとして、、今後大丈夫か？
第2章チーム分析とDevOpsの実践
Airワーク開発体制(ヒト) AWS(システム)参画時の開発体制とそれぞれの担当部分について一見すると違和感のない体制かつ役割分担に見えるAirワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearch
Airワーク開発体制(ヒト) AWS(システム)参画時の開発体制とそれぞれの担当部分についてAirワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearch実はサービス全体の運用の専任者はいない問題発生ベースで全力対応はするが、予防や改善活動などまで手が回らない状態インフラT ≠ 運用Tリリース作業などの定常作業は開発Tが担当
他システム体制Airワーク開発体制参画時の開発体制とそれぞれの担当部分についてインフラTが運用/改善の主体になればと考えたがそもそもそのためのチームではないことを認識Airワーク開発Tバックエンド担当フロントエンド担当横断インフラTインフラ担当他開発Tバックエンド担当フロントエンド担当安定稼働担当インフラ担当インフラ障害や問い合わせ , 保守対応で必要なことがあればお互いに連携AWS障害や問い合わせ , 保守対応で必要なことがあればお互いに連携インフラに関するスキルは持っているが、横断的にサポートをするのがメイン各サービスの運用や改善の推進はサービス側が主導する座組である
Airワーク開発体制(ヒト) AWS(システム)開発体制の移り変わり1 (構築時)初期構築時は強力な助っ人Tの参画によりインフラ、アプリの一部とCI/CDやモニタリングシステムの構築を実施Airワーク開発Tバックエンド担当フロントエンド担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearch助っ人Tアプリもインフラもできる人達ローンチ後もある程度見据えてCI/CD, モニタリングの仕組みも構築
Airワーク開発体制(ヒト) AWS(システム)開発体制の移り変わり2 (ローンチ後しばらく)ローンチ後に助っ人Tが抜け、しばらくは開発Tで全体をまかなおうとしたしかしナレッジの継承、引き継ぎがうまくいかずトラブルが出てきだしたAirワーク開発Tバックエンド担当フロントエンド担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearchサービスだけでも厳しいのでこのあたりまで手が回らずエンハンスによってこのあたりも追加されていき管理するものが増える
Airワーク開発体制(ヒト) AWS(システム)開発体制の移り変わり3 (インフラT参画)その後今のかたちに落ち着いたAirワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearchインフラ部分のサポート要因として参画
Airワーク開発体制開発体制の移り変わりまとめまとめるとこんな感じAirワーク開発Tバックエンド担当フロントエンド担当助っ人Tアプリもインフラもできる人達Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当
Airワーク開発体制開発体制の移り変わりまとめAirワーク開発Tバックエンド担当フロントエンド担当助っ人Tアプリもインフラもできる人達Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当初期構築時はなんでもTがインフラ構築だけでなく運用見据えたCI/CDやモニタリングの構築もしてくれたインフラ担当 = 運用/改善ができる人達という認知が生まれた構築以外にもCI/CDやモニタリングの構築もしたし開発Tに引き継げば運用もうまくいくだろう仕組み化によって運用/改善も回るという期待が生まれた初期構築時はローンチに向けて最適な体制を選択ただ、この時点で長い目で見たときのリスクの種を植えていた
Airワーク開発体制開発体制の移り変わりまとめAirワーク開発Tバックエンド担当フロントエンド担当助っ人Tアプリもインフラもできる人達Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当ローンチ後にインフラ部分もやるようにしたが、勝手がわからず、トラブルも増え、開発Tでインフラ担当するのはとにかく大変である。という認識になる1度は開発Tですべてをやることにトライしてみるが、結果インフラ周りは専門の人達に任せるべきという認識になる加えて助っ人Tが残してくれた資産も引き継いだものの実際運用していくとなると分からないことだらけで、維持することだけに手一杯になる
Airワーク開発体制開発体制の移り変わりまとめAirワーク開発Tバックエンド担当フロントエンド担当助っ人Tアプリもインフラもできる人達Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当そして今、体制移り変わりによってお互いのチームに対する認識齟齬が生まれていたこの構造を解消しない限り運用周りの課題は発生し続けるトラブルを経てインフラT参画してくれたことによりインフラ + 運用も任せれるという期待になった各システムのインフラ支援がメインで能動的な活動は各開発Tがやるという認識依頼ベースで対応はするが全体推進は開発Tという期待
Airワーク開発体制(ヒト) AWS(システム)実際の不安要素Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearchアーキAWSで突発的な障害が出た時に、検知はするものの開発とインフラが別々に調査をしていたり見てますこういうアプリエラー出てます見てますこういうインフラ障害出てます障害発生！協力してみましょう
Airワーク開発体制(ヒト) AWS(システム)実際の不安要素Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearchアーキ問題検知しても体制上どうしても案件優先になり対応が後手にまわってしまうストレージ利用量が逼迫しているので対応お願いします案件で手一杯のため増加対応でお願いしたいです。。cronjobの履歴が残っているだけなので、履歴数を減らしましょう
Airワーク開発体制(ヒト) AWS(システム)我々の参画によりやってきたことAirワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当EC2バックエンドアプリケーションフロントエンドアプリケーションk8sS3SESRDSElastiCacheサービス CI/CDシステムEC2ConcourseCIRDS監視/ログシステムDatadogElasticSearchアーキ構造を理解した上で我々の活動を振り返るとアプリ, インフラという垣根を気にせずサービス全体でものごとを捉えて改善実践するアプローチだったデプロイ速度改善モニタリング改善スロークエリ改善スケール案検討
Airワーク開発体制理想的な体制Airワーク開発Tサービス全体の運用/改善を考えると職能で分離したチーム体制ではなく、役割ごとの分離&足りないスキルを補う体制がよいのではと考える開発T(価値提供目的)運用T(安定稼働目的)バックエンド担当フロントエンド担当安定稼働担当インフラ担当(ヘルプとして兼務 )1つのチームとして開発 /運用スキルを担保する
Airワーク開発体制これってDevOpsでは？Airワーク開発T目指したいことはDevOpsと気付きDevOps的なアプローチで進めれないかを思考し始めた開発T(価値提供目的)運用T(安定稼働目的)バックエンド担当フロントエンド担当安定稼働担当インフラ担当(ヘルプとして兼務 )1つのチームとして開発 /運用スキルを担保するこれ自体が「市場指向チーム」という考え方に近いことに気付く
開発TそもそもこれもDevOpsだったのでは？これまでやってきた活動も見方を変えるとDevOpsに則った活動だったと解釈アーキテクトインフラT1.システム負荷モニタリング項目追加スケール対策検討アラート見直し2.運用負荷デプロイ改善テスト環境拡張3.品質劣化設計/コードレビュー..その他発生ベースで適宜優先度判断具体案検討タスク化適宜対応依頼運用課題目標利用拡大に耐えれる状態の構築共通の目標に向かって協働する
DevOpsの原則である3つの道を考えるバリューストリームの理解も気になったが今の状態ではなぜ改善するかを理解することそのうえで改善を根付かせることの2点が重要と判断1. フローの原則CI/CDといった仕組みはすでにある週1回リリースサイクルだがこれが遅いという話は出ていない2. フィードバックの原則自動テストの仕組みはすでにあるモニタリングにやや不備があったが改善済み3. 継続的な学習と実験の原則圧倒的にここが不足している開発作業がメインだったため日常業務の改善をしたり、今の状態や目指すべきものといった考え方がそもそもない
Airワーク開発体制「運用連絡モデル」を参考に実践Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当アーキ開発Tリーダーと相談して安定稼働専任者を建ててもらい、我々がフォローする形で開発Tの運用力向上を測ることに安定稼働担当 指導安定稼働担当に・課題に対する優先度決めと理由・対策の具体案検討・改善施策の目的言語化などを考えてもらいレビューやフォローをする安定稼働という名目で専任者を2名建てる
開発Tこの体制で我々の裏の目標も策定これまでやってきた活動をベースに体制をチューニングアーキテクトインフラTAWS知識不足運用スキル不足.. etc適宜対応依頼目標利用拡大に耐えれる状態の構築共通の目標に向かって協働する裏目標自立的に運用/改善活動ができる状態の構築安定稼働担当指導課題
ビジョンと理想, 現実のギャップ整理アーキまずは運用をしていくうえで自分たちは何のために存在し、何を目指したいのかを言語化安定稼働担当指導 ビジョン作成何のためにいるチーム？どういう状態になりたい？理想と現実のギャップ発生障害の対応・修正(恒久含む) にしか手が回っていない障害対応として 予防 ＞ 早期発見・治療＞ 発生障害の対応・修正(恒久含む) としたい現状 理想レビューやデプロイ, 結合テスト手戻り等スピードを妨げる要因を認識しているが、フローの可視化や根本部分の解消はできていない課題創出が有識者, アーキ → 安定稼働T となっており、優先順位付けも有識者に依存しているチーム内で 課題創出、判断、対応のサイクルが回っており、必要に応じて安定稼働T → 有識者, アーキ への依頼ルートを取れる開発者が滞りなく開発作業を実施し、製造〜リリースまでのリードタイムが最小化されている環境を維持する基本品質の担保魅力品質向上自己組織化チーム
残課題を中心に対応方針検討を実施残課題についても目的を明確に、視野を広く、効果を実感できる形で実施してもらうマニフェストフロントエンドバックエンド＋アプリレイヤ以外の部分も徐々に手掛ける結果を定量的に測るためにモニタリングツールの活用を始めるHow指向ではなくWhy指向にバッチ処理によるCPU負荷高騰のアラートが増えるアラートを減らせないか？そもそもこのアラートは必要なのか？事象HowWhyアーキ 安定稼働担当指導この課題についてこのように対応しようと思います背景や目的は？その方法以外に選択肢は？改善結果は見れる？
徐々に起き始める変化安定稼働のために徐々に主体的な動きが出てくるようになるアーキ 安定稼働担当このアラート最近頻発してるので調査と対策優先させたいですいいね！調査するにはこういうところ見るといいよこの障害については振り返り必要だと思うので実施しますポストモーテムとか参考にして、仕組みで対策できないかなど考えてみてください
開発, インフラTの連携も別で検討開発T内の立ち上げとは別に開発, インフラTの連携強化についても検討Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当アーキ安定稼働担当 ワンチームで改善をするにはここの連携強化が必須
開発, インフラTの連携リーダー陣での連携強化とサービス安定稼働の側面で両チームが定期的に追うべき指標を洗い出し、共同で確認していく体制を確立Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当安定稼働担当開発TリーダーインフラTリーダー私・課題認識共有・優先度すり合わせ・案件状況共有Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当安定稼働担当インフラ観点・CPU使用率・メモリ使用率・ストレージ使用率… etcアプリ観点・Webレイテンシ・エラー率・変更失敗率・バッチ時間… etc1.リーダー陣での連携強化 2.サービス安定稼働に関する共通指標を策定&共同確認これらを両チーム共同で定期確認
開発, インフラTの連携結果、最近のモニタリングで問題を早期に発見し対策するという動きもできているAirワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当安定稼働担当開発TリーダーインフラTリーダー私・課題認識共有・優先度すり合わせ・案件状況共有Airワーク開発体制Airワーク開発Tバックエンド担当フロントエンド担当インフラTインフラ担当安定稼働担当インフラ観点・CPU使用率・メモリ使用率・ストレージ使用率… etcアプリ観点・Webレイテンシ・エラー率・変更失敗率・バッチ時間… etc1.リーダー陣での連携強化 2.サービス安定稼働に関する共通指標を策定&共同確認これらを両チーム共同で定期確認最近これらが跳ねる傾向を検知し安定稼働Tを中心に対策中最近特定のアクセスでこれらが跳ねる傾向を検知し安定稼働Tを中心に対策中
このまま順調にいくと思っていたが開発チームの運用力向上が軌道に乗りかけてたが、10月末で1名離任が決定当初具体的な対応を保留していた品質についても温度感が高まる安定稼働担当1. 安定稼働担当の1名が離任、、あとはお願いします！アーキ2. 2021年上期(4~9月)を通じてアプリ更新起因の障害がやや増加2020年下期(10~3月) 2021年上期(4~9月)障害率約10%増加
第3章自立と連携への歩み出し
離任影響を分析もともと2名とも運用/改善活動以外に案件系タスクもしていた1名体制になるとほぼ間違いなく回らなくなることが予想された離任による影響を分析安定稼働のリーダー格 (離任されたのはこちら )・優先度決め、タスク差配 /実行などの実施・運用業務の他にバックエンドチームの取りまとめも兼任安定稼働のメンバー・運用/改善業務の実稼働をメイン・その他フロントエンドチームの取りまとめや案件の要件定義なども兼任AさんBさん
品質について分析要求分析要件定義基本設計詳細設計開発/製造 コードレビュー単体テスト結合テストシステムテスト受け入れテストここはテスターさんが実施ここでのバグ検知がそもそも多い(特にUI系)ここは開発者が実施ここでのテスト粒度が人によってバラバラ(人員増加によって従来の緩いルールだとムラが出るようになった)・開発, テスター間の連携不足によりテストすべき内容に漏れが発生・UI系が特に手戻りが多い(上期も多かったが10~12月に更に発生、バグ全体の半分以上 )の2点が品質、開発フローにおける課題ということが見えてきたテスター、開発者間でのテストケースレビューがない
先にネタバレ実は第3章は我々が手厚くフォローしたのではなく現場で自立的に進めたものがメインになります(適宜アドバイスはしたが取捨選択は委ねた)
安定稼働担当離任については定常タスク移管とメンバー自立の2軸で対策Bさんが担っていた部分をメンバーでもできるようにして、Aさん離任の穴を全体で埋める優先度、対応方針決めタスク分解と差配Bさん(リーダー)アラート対応など定常タスクの対応その他運用/改善系タスクの遂行フロントエンド担当バックエンド担当Bさん(リーダー)今まで案件内容の理解やタスク化を Bさん頼みにしていたが設計含めて各人がこなすようにしていく各人の進捗確認困りごと対応、レビュー
品質(テスト漏れ)については単体テスト方針とテスターとの連携で対策これまで各担当者に任せきりになっていたテスト全般についてルールを整備プロセスを重くして品質を上げるではなくチーム間の連携により全体で品質を守るアプローチを取った単体テスト方針改修に併せてテストコードでどこまで担保するのか？- 条件網羅、カバレッジ、境界値などの考え方整理テストコードで担保しない部分についてどこまで手動テストで担保するのか？- UIテスト、ブラウザ網羅などテスター連携役割分担- バッチや内部処理などテストが難しい場所は開発で担保- 回帰テストや案件ごとの細かな UIテストはテスターで担保案件内容の共有- 案件意図に合わせたテストができるようにテスターも案件理解に加わるなど
品質(UIバグ多い)についてはデザイナーとの連携で対策ここでもチーム間の連携強化により最適な方法を模索することにしたデザイン不備がとにかく多かった深ぼったところ、デザイナーが Figmaで記したデザインをそのまま個別に CSSで表現していた→ 「実はこことここは同じデザイン」といったデザイナーの意図をコードに反映させておらず 修正漏れが多発していたデザイナーとの連携を強化デザイナーとUIコンポーネントの定義やデザイン思想の認識合わせを実施デザインの意図を徐々にコードに反映させていくことに
結果、フロー, フィードバック面でも改善が進んだ開発フローで発生していた認識齟齬とそれによる手戻りを早期検知&改修できるようにこれまで 要件定義 設計デザイン コーディング 単体テスト開発者 デザイナー テスター結合テスト開発 テスト開発者 開発者 開発者ここの間の連携ができておらず後工程での手戻りが多発していたここの間の連携ができておらず後工程(特に結合テスト)での手戻りが多発していたこれから 要件定義 設計デザイン コーディング 単体テスト開発者 デザイナー テスター結合テスト開発 テスト開発者 開発者 開発者ここの間の連携ができておらず後工程での手戻りが多発していた連携強化によりお互いの早期FBとそれによるフロー改善ができた
定量的に見た結果定量的にも改善傾向が明確に出た結合テストのUIバグ件数 約1/5アプリ更新起因の障害 約1/3Before(10~12月) After(1~3月)
残課題も開発T、インフラTが連携して継続実施安定稼働主体でインフラが絡む課題についても対応を実現安定稼働担当インフラTnode group(CL用)node group(CS用)VPCk8sクラスタWeb用Web用バッチ用構成的によくなかった部分の解消アーキ実施アドバイス node group(バッチ用)
関わり方は参画前の認識になってきた参画する前はこう考えてた 開発T: 現状こういう状態で、利用拡大に伴ってやばくなりそうな箇所はここです → 現場に課題認識があり技術難度の高いところを中心にフォロー参画直後はこうだった 開発T: 利用拡大に伴いどうなるかわからない、、 サーバリソースのどこに響くのかとかよくわからない、、 → 現場での現状整理ができておらずここから実施が必要 → 直近の対策はできたとして、、今後大丈夫か？最近はこうなりつつある 開発T: この課題対応にはこうするとよいと考えていますが、見解やアドバイスほしいです → 課題認識と対応検討を主体的に進め、技術難度の高いところをフォロー
よく聞く理想のDevOpsにはまだまだ遠いが1日100回デプロイといった世界には遠いが、組織としてもシステムとしても徐々に良い方向には向かっているまだまだ課題も多いが、だからこそ学習し続けることに価値があると考える1. フローの原則開発フロー上の無駄を一部排除週1回リリースサイクルのままだがチーム連携という動きは生まれつつある2. フィードバックの原則システム的なフィードバックはそのままチーム間のフィードバックという好循環ができつつある3. 継続的な学習と実験の原則まだ時折HOW思考に陥ったり、目指すべき状態を見失うこともあるが、運用力は強化されつつある
我々がやってきたことまとめ1. 事業要望に応えるためにシステム改善に注力した(エンジニアリング的アプローチ)→ 改善によるシステム安定化2. 改善継続には現場の自立が必要と認識してスキル, 考え方の注入をした(ヒト的アプローチ)→ 超人がいないと成り立たないではなく自己組織化を目指す3. 1つのチームとして連携できるように共通の指標を立てた(ヒト的アプローチ)→ システム安定稼働をチームで守るという意識付けヒトとエンジニアリングの両軸でアプローチすることでDevOps的な文化を生みだせる！大事なのはチームとしてどうしていきたいか？を考え、実践していくことです。
「どうしていきたいか？」 → 「あなたはどうしたい？」一緒に自己組織化したチームで働きませんか？弊社では「あなたどうしたい？」という問をもとに自立して働く方を募集中です！
recruitengineers
trycycle
bcantrill
tsutaj
salaboy
victorrentea
hosimesi11
isaoshimizu
kthrtty
goyoki
bun913
charmichokshi
yayoi_dd
eileencodes
shpigford
smashingmag
lara
geoffreycrofte
akosma
ufuk
davidbonilla
cromwellryan
afnizarnur
revolveconf
schacon