Download as PDF, PPTX
![43
インフラの整備状況の予実
実施した施策 予定 実績
単純にCIサーバ数を増やす 1ヶ月 1週間
マスタースレーブ構成を適用する 1～2ヶ月 1週間
Infrastructure as Codeを適用する 2ヶ月 1ヶ月
[要因]
• 直井さん主導による、インフラ担当者との迅速な折衝
• 若者の人間離れ（≒メンバーの予想以上のがんばり）](https://image.slidesharecdn.com/conquerciserveragilejapan2015ja-150414002538-conversion-gate01/85/CI-43-320.jpg)
![46
採用前 採用後
1週間 30分
[要因]
• コミュニケーションミスによる依頼の往復を、
ほぼ無くすことができた
• エンジニアが動作確認したものをインフラ担当者が実施する
だけなので、作業自体が容易になった
• 万が一トラブルが起きても、
Immutable Infrastructureなので簡単に復旧できる
Infrastructure as Codeの有益性 (1)](https://image.slidesharecdn.com/conquerciserveragilejapan2015ja-150414002538-conversion-gate01/85/CI-46-320.jpg)
![57
09:40:04 up 154 days, 19:14, 2 users, load average: 11.59,
11.32, 7.16
[Heavy Process Top 10] CPU(%), Proccess
165 xxxxx
アラートメール (1) ：改善前
• uptimeコマンドを使っているが、情報が冗長
• CPU使用率の高いプロセスは特定できるが…
• プロセスのユーザは特定できない
• 何が問題でどう解決すれば良いのかの情報が少ない
• メモリ使用率の高いプロセスは分からない
• どのジョブが原因なのかを特定できない
そもそもスペルが
間違っているぞ！](https://image.slidesharecdn.com/conquerciserveragilejapan2015ja-150414002538-conversion-gate01/85/CI-57-320.jpg)
Uploaded byRakuten Group, Inc.
CIサーバを制圧せよ！ - プロジェクトメトリクスと自動化技術の活用よる混乱の収拾と「最強」の組織の育成
2015年4月16日に開催されました、「Agile Japan 2015」で発表させていただいた資料の詳細版です。 http://www.agilejapan.org/ プロジェクトメトリクスによる具体的な改善の実践例、およびマネージャ層の方との協力のあり方についてまとめています。 あなたのチーム・組織の改善のヒントになれば幸いです。
More Related Content
Similar to CIサーバを制圧せよ！ - プロジェクトメトリクスと自動化技術の活用よる混乱の収拾と「最強」の組織の育成
CIサーバを制圧せよ！ - プロジェクトメトリクスと自動化技術の活用よる混乱の収拾と「最強」の組織の育成
- 1. CIサーバを制圧せよ！ プロジェクトメトリクスと自動化技術の活用よる 混乱の収拾と「最強」の組織の育成 Apr/16/2015 Hiroyuki Ito, KazuhisaNaoi Rakuten, Inc. http://www.rakuten.co.jp/
- 2. 2 伊藤 宏幸 (TheHiro) @hageyahhoo アジャイルコーチ TDDグループ（当時） 自己紹介 (1)
- 3.
- 4. 4 自己紹介 (2) 直井 和久 楽天株式会社 トラベルサービス開発・運用部 トラベルサービス開発課 TravelExtranetグループ マネージャー
- 5.
- 6. 6 2. 戦略策定の重要性 3. Infrastructureas Codeの有益性 お伝えしたいこと 1. プロジェクトメトリクス 4. Technology-Driven Development
- 7.
- 8. 8 アジェンダ 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理
- 9. 9 アジェンダ 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理 戦略策定の重要性 Infrastructure as Codeの有益性 Technology-Driven Development プロジェクトメトリクス プロジェクトメトリクス プロジェクトメトリクス プロジェクトメトリクス
- 10. 10 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理
- 11.
- 12.
- 13. 13 当時の我々の状況 お互い、CIサーバの設定・監視・運用には 責務を持っていなかった。 とあるQAプロジェクトの自動化を主導中 • ビルドパイプラインの構築 • リリース自動化の実現 •スモークテストの構築 メインシステムの多言語化対応を マネージャとして主導中
- 14.
- 15. 15 原因分析結果 400以上のジョブ （さらに増加の傾向） スタンドアローン構成 実行待ちキューが 10前後なのもザラ Load averageが 10を超えるのはザラ そもそも画面すら開けないことが多かった。 • 「ScriptConsole」を試すこと自体がバクチ 誰も監視・メンテ していない！ 重い…
- 16.
- 17.
- 18.
- 19.
- 20. 20 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28. 28 2. CIサーバのボトルネックを解消する • CIサーバ群をマスタースレーブ構成に改め、負荷分散を容易化する。 •既知の技術負債等を1つ1つ解決し、CIサーバ群を「クリーン」にしていく。 3. CIサーバの使い方を教育していく 利用者（エンジニア）にCIサーバの「正しい」使い方を教えることで、 技術負債・トラブルの芽を摘むと同時に、利用者の育成も図る。 2. 基本戦略 1. 取り急ぎCIサーバの負荷を減らす • 高負荷ジョブを一時停止するなどして、一時しのぎと改善の時間稼ぎをする。 • 負荷分散用サーバを調達・整備し、ジョブを各サーバに「一時疎開」させる。 4. 専任チームを後進に引き継ぐ • 伊藤・直井がリードする体制から、育成も兼ねて後進にタスクを引き継ぐ。 • 結果として、CIサーバの「正しい」使い方をさらに広めることも図る。
- 29.
- 30.
- 31. 31 プロジェクトメトリクスの候補 (2) 負荷 アラートメール数の推移 （※後述） 各サーバの負荷の推移 •Load average • CPU % • IO wait % • ディスク使用量 各ジョブの平均実行時間・平均待ち時間の推移 実行待ちジョブ数の推移 （特に負荷の高い）ジョブの実行頻度とその推移 利用者が「CIサーバが重い」と感じることが どれぐらい減ったか？ （Gut feel）
- 32.
- 33. 33 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理
- 34.
- 35.
- 36.
- 37. 37 この時点で計測したプロジェクトメトリクス (2) 負荷 アラートメール数の推移 各サーバの負荷の推移 • Loadaverage • CPU % • IO wait % • ディスク使用量 各ジョブの平均実行時間・平均待ち時間の推移 実行待ちジョブ数の推移 （特に負荷の高い）ジョブの実行頻度とその推移 利用者が「CIサーバが重い」と感じることが どれぐらい減ったか？ （Gut feel）
- 38.
- 39. 39 (1) 単純にCIサーバ数を増やす 4台増強 メイン機 弐号機 参号機量産機 量産機 負荷の高いジョブを 一時疎開する 次のステップのための 時間稼ぎをする まずメイン機の 負荷を減らす
- 40. 40 (2) マスタースレーブ構成を適用する マスター スレーブ1 スレーブ2スレーブ3 スレーブ4 ジョブを 分散実行 監視の仕組みも 導入・強化（後述） マスターサーバに 改造
- 41. 41 (3) Infrastructure asCodeを適用する マスター スレーブ1 スレーブ2 スレーブ3 スレーブ4 マスターを正とし、 設定をスレーブと同期 設定がコードなので 分かりやすい Immutableなので 壊されても復元可能
- 42.
- 43. 43 インフラの整備状況の予実 実施した施策 予定 実績 単純にCIサーバ数を増やす1ヶ月 1週間 マスタースレーブ構成を適用する 1～2ヶ月 1週間 Infrastructure as Codeを適用する 2ヶ月 1ヶ月 [要因] • 直井さん主導による、インフラ担当者との迅速な折衝 • 若者の人間離れ（≒メンバーの予想以上のがんばり）
- 44.
- 45. 45 0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125 130 アラートメール数 (2014/08/01 -2014/09/30) アラートメール数の推移にみる負荷減少 8月 241通 9月 108通 55.2%の 削減！ ジョブ増加で一時的に 負荷が高まったが、 リリースできないという 最悪の事態は再発せず。 サーバのload averageが 10を越えたらこれを通知する 仕組みが元々あったため、 これを活用した。
- 46. 46 採用前 採用後 1週間 30分 [要因] •コミュニケーションミスによる依頼の往復を、 ほぼ無くすことができた • エンジニアが動作確認したものをインフラ担当者が実施する だけなので、作業自体が容易になった • 万が一トラブルが起きても、 Immutable Infrastructureなので簡単に復旧できる Infrastructure as Codeの有益性 (1)
- 47. 47 Infrastructure as Codeの有益性(2) startup.shの権限を、 774から777に変更してほしい 以前のインフラ運用体制 エンジニア インフラ担当 madokaグループの homuraユーザで、 Tomcatを起動・停止 できるようにしたい shutdown.shが実行できない！ homuraユーザがmadokaグループに入っていない！ startup.shの権限を、 777に変更しました
- 48. 48 Infrastructure as Codeの有益性(3) 個々のサーバで 構成が異なることが多いため、 事前確認で漏れを無くすことが困難 実際に動作確認するまでは 安心できない 大概、依頼内容および設定結果に 誤りがある 以前のインフラ運用体制 エンジニア インフラ担当 指示された通りの設定は （大体）できる なぜその作業を依頼されたのか、 その意図・目的までは伝わりづらい 大概多忙なので、 作業が後手にまわりがち コミュニケーションミスが 多発しがち やり取りが多くなりがちで 時間がかかる
- 49.
- 50. 50 Infrastructure as Codeの有益性(4) 新しいインフラ運用体制 Recipeとテストコードを 実行すれば良い ダメだったら設定を戻せばよいので、 作業上のリスクが少ない 必要な全ての設定は、 Recipeとテストコードとして残せる Recipeとテストコードの Pull Requestで、 手戻りの少ない作業依頼が出来る 依頼前に各自のPCで 構築・動作確認が出来る エンジニア インフラ担当
- 51. 51 （再掲） インフラの整備状況の予実 実施した施策 予定実績 単純にCIサーバ数を増やす 1ヶ月 1週間 マスタースレーブ構成を適用する 1～2ヶ月 1週間 Infrastructure as Codeを適用する 2ヶ月 1ヶ月
- 52.
- 53. 53 マスターサーバの負荷軽減の副次的効果 マスター スレーブ 下記のような詳細な情報を スクリプトで機械的に 取得できるようになった • ジョブ一覧 • 実行時間の推移 •スレーブの情報 アラートメールが 激減した “Script Console”が 使えるようになった！ アラートメールを 改良する余裕が生まれた 負荷の高いジョブの 実行頻度の調査が容易に より詳細なプロジェクトメトリクスの計測と 改善が可能に！
- 54.
- 55. 55 新たに計測し始めたプロジェクトメトリクス (2) 負荷 アラートメール数の推移 各サーバの負荷の推移 • Loadaverage • CPU % • IO wait % • ディスク使用量 各ジョブの平均実行時間・平均待ち時間の推移 実行待ちジョブ数の推移 （特に負荷の高い）ジョブの実行頻度とその推移 利用者が「CIサーバが重い」と感じることが どれぐらい減ったか？ （Gut feel）
- 56.
- 57. 57 09:40:04 up 154days, 19:14, 2 users, load average: 11.59, 11.32, 7.16 [Heavy Process Top 10] CPU(%), Proccess 165 xxxxx アラートメール (1) ：改善前 • uptimeコマンドを使っているが、情報が冗長 • CPU使用率の高いプロセスは特定できるが… • プロセスのユーザは特定できない • 何が問題でどう解決すれば良いのかの情報が少ない • メモリ使用率の高いプロセスは分からない • どのジョブが原因なのかを特定できない そもそもスペルが 間違っているぞ！
- 58. 58 • uptimeコマンドの実行結果を、load averageのみに絞った •CPU使用率に加え、メモリ使用率の高いプロセスも 特定・出力するようにした • 当該プロセスのユーザを特定・出力するようにした • 原因となるジョブ名を特定・出力するようにした 但し、一番下に出力しているため、 都度メールを一番下まで見なければならない アラートメール (2) ：改善開始 Load average: (1.03, 1.05, 1.23) --- Top 10 Heavy CPU consumers --- tomcat xxxxx --- Top 10 Heavy Memory consumers --- ito xxxxx --- Jobs currently running --- - Sayaka
- 59. 59 原因となるジョブ名を、メールの最初に出力するようにした • ジョブの特定が非常に容易になった （メールを開けば一目で分かる） • 問題のあるジョブの特定と原因調査が、非常に容易になった •と言うよりも、この時点で初めてこれができるようになった アラートメール (3) ：更なる改善 Load average: 10.0, 5.2, 2.4 --- Jobs currently running --- - Sayaka --- Top 10 Heavy CPU consumers --- tomcat xxxxx --- Top 10 Heavy Memory consumers --- ito xxxxx
- 60. 60 （特に負荷の高い）ジョブの実行頻度とその推移 ジョブ名 アラートの頻度 Madoka 32 Homura17 Sayaka 15 Anko 13 Mami 13 Charlotte 4 QB 3 Hitomi 2 Uro-Buchi 2 負荷の高いものから （スレーブへの移行などの） 対応を優先的に行なう これを週次で関係者へ メール通知することで、 自発的な活動を促す
- 61.
- 62.
- 63. 63 プロジェクトメトリクスの振り返り (1) 業務への支障の 減少度合い 「リリース待ち」・「リリース遅延」の 発生頻度と増減の推移 インフラの 整備状況 サーバ準備タスクの予定・実績の差異 • 待ち時間・作業割込時間も併せて計測する 全ジョブをスレーブで実行できるようにするまでの 総タスク数と、その予定・実績の差異 サーバの設定変更およびプロビジョニングにかかる 時間とその推移 マスタースレーブ 構成に改めた成果 各ジョブのスレーブへの移行率と推移 各ジョブのスレーブでの稼働率・成功率と推移 トラブルに関する 問合せとその対応 問合せ件数・解決件数と推移 各問合せの解決までにかかった平均時間と推移 予想以上に早く片付く •見せる成果としては十分 • 要因は分析済で、知見は今後に活かせる • 作業終了につき、計測終了 • マスターの高負荷発見時、 ジョブの対応要否を判断する材料として活躍 • 必要な時だけ閲覧できれば十分で、 常時監視は不要
- 64. 64 プロジェクトメトリクスの振り返り (2) 負荷 アラートメール数の推移 各サーバの負荷の推移 • Loadaverage • CPU % • IO wait % • ディスク使用量 各ジョブの平均実行時間・平均待ち時間の推移 実行待ちジョブ数の推移 （特に負荷の高い）ジョブの実行頻度とその推移 利用者が「CIサーバが重い」と感じることが どれぐらい減ったか？ （Gut feel）
- 65. 65 プロジェクトメトリクスの振り返り (2) 負荷 アラートメール数の推移 各サーバの負荷の推移 • Loadaverage • CPU % • IO wait % • ディスク使用量 各ジョブの平均実行時間・平均待ち時間の推移 実行待ちジョブ数の推移 （特に負荷の高い）ジョブの実行頻度とその推移 利用者が「CIサーバが重い」と感じることが どれぐらい減ったか？ （Gut feel） • 報告および改善要否の判断については、 次の2つの情報だけで十分だと分かった • アラートメール数 • （特に負荷の高い）ジョブの実行頻度と その推移 • 他の情報は、詳細分析が必要な時だけ 見れば十分
- 66.
- 67. 67 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理
- 68.
- 69.
- 70.
- 71. 71 ツールの乱立 • Cobertura • Emma(JaCoCo) •djUnit… UTカバレッジの 計測手段と メトリクスの不足 UTカバレッジに関する当時の課題 12.3% 05101520253035404550556065707580859095100105110115120125130 施策をリードする メンバーの不足
- 72.
- 73.
- 74. 74 計測対象ジョブ数 74 うちカバレッジを 取得している数 67 目標達成済 ジョブ数 35 達成率 47.3% (+18.9% WoW) (2)カバレッジの推移を、週次で記録・報告するようにした 先週比を追加し、 成長の共有と 成果の強調を図った
- 75.
- 76.
- 77. 77 当初は、不足気味の「作業者」の補充として 徴収・組織したが… 「65%チーム」の真の姿 本当の目的は、Jenkins Consolidation Teamと そのタスクを引き継ぐこと！ •伊藤らの支援期間が年末で切れるため 「65%チーム」のメンバーは、 引継ぎ対象と同時に育成対象でもあった。
- 78. 78 プロジェクトメトリクスと自動通知とを活用した、 目標・課題・進捗の共有による コラボレーションの促進 自動化技術による業務効率化 • Infrastructure asCode • CIサーバ自体の適用範囲の拡大 自動化技術とプロジェクトメトリクスを活用した、 「検査と適応」による学習の促進 育成指針としてのTechnology-Driven Development
- 79.
- 80. 80 プロジェクトメトリクス情報を元に、 次の行動を考え実践する癖をつけてもらった Infrastructure as CodeとOJTとで、 我々の実務を少しずつやってもらうようにした 課題を報告してもらうだけではなく、 どうすれば解決できるかに意識を移してもらった メンバーに徐々にチーム運営を任せていった •メンバーの自主性を刺激してみた 「65%チーム」の後期の運営 （作業引継対象としての育成）
- 81.
- 82. 82 Infrastructure as CodeとOJTとで、 実際に実務を代行できるようになってきた •12月時点で、約10件の業務を代行 UTカバレッジが目に見えて向上してきた • UTカバレッジの向上が更なるモチベーション を生む、プラスのサイクルが生まれた 問題を起こしているチームを見つけたら、 自発的に解決を手伝うようになった 「65%チーム」の成長
- 83.
- 84.
- 85.
- 86. 86 2. 何を持って成果とすべきか？ 3. どうやってCIサーバの負荷を減らすか？ 4.どうメンバー・チームを育成していくか？ 5. 結論 1. 課題の整理
- 87.
- 88.
- 89.
- 90.
- 91.
- 92.
- 93. 93 プロジェクトメトリクスのポイント 考えることのプラスになる情報を見つけよう • 現状の問題はどこにあるのか？ • 改善施策の効果はあったか？ メトリクスを定期的に振り返り改善していこう •役に立たなければ、潔く捨てる覚悟も必要 • 足りなければ創ろう 数値の変化に意味を見いだそう • 数値の変化にこそ、真の知識が詰まっている • 変化が見える情報を見つけることが勝利の鍵 コミュニケーションの手段として活用しよう • 今まで分からなかった情報を元に話をしてみると、 更なる発見が得られる
- 94.
- 95.
- 96. 96 参考資料 『Useful Metrics ina Complex World』（Agile2014） http://www.agilealliance.org/files/9814/0509/9343/Experienc eReport.2014.Power.pdf 『Moneyball for Software Projects』 （Agile2014） http://schd.ws/hosted_files/agile2014/f0/1272_Agile_2014_- _Software_Moneyball_%28Troy_Magennis%29.pdf 『Technology-Driven Development』 （Agile2014） http://www.agilealliance.org/files/5014/0509/9284/Experienc eReport.2014.Ito.pdf 『メトリクスによる「見える化」のススメ: エッセンシャル・リーン』 http://www.slideshare.net/ssuser968fab/xp-matsuri- 2014ltthehiro