Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2018-14-DevOps

 2018-14-DevOps

- 開発を加速させる文化・プラクティスを知る
 - キーワードを広く
 - 深くは解説しない

Cybozu
PRO

June 18, 2018
Tweet

More Decks by Cybozu

Other Decks in Programming

Transcript

  1. DevOps 生産性向上チーム 宮田 淳平 1

  2. この講義の目的 ▌開発を加速させる文化・プラクティスを知る ⚫ キーワードを広く ⚫ 深くは解説しない 2

  3. DevOpsとは 3

  4. よくある目標の対立 4 開発 運用 どんどん リリースしたい! 安定運用! 壁

  5. なにが問題なのか? ▌高速リリースは運用と協力しないとできない ⚫ トラブル対応ばかりになって開発が進まなくなってしまう ▌安定運用は開発チームの協力がないと実現できない ⚫ サービス側を修正しないとその場しのぎの対応になりがち 5

  6. 6 https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops- cooperation-at-flickr

  7. 共通のゴール 7 開発 運用 素早く安全なリリースを繰り返して ビジネスゴールを達成する!

  8. DevOpsの広がり ▌開発と運用だけの話ではない ▌DevOpsQA, DevSecOps, BizDevOps, などなど ▌ビジネスゴールの達成を加速させることが本質 8

  9. 組織構造の話? ▌だけではない ▌共通のビジネスゴールの達成を加速させるためには、 プロセスや技術的なプラクティスも重要 9

  10. 結局DevOpsって? ▌厳密な定義はない ▌生産性を上げるための ⚫ 組織文化 ⚫ プロセス ⚫ 技術的プラクティス ▌ぐらいの認識でいい

    11
  11. DevOpsを支える3つの道 12

  12. 13 https://cybozu.co.jp/company/job/recruitment/bus iness/

  13. なにを開発すれば 世界一使われるグループウェア になるか? 14

  14. わからない! ▌顧客にもわからない ▌さらに市場は変化していく 15

  15. ではどうするか? 1. 仮説を立てる 2. 顧客に価値を届ける 3. フィードバックを受け取る 4. 1.〜3.を繰り返す 16

  16. 仮説検証の繰り返しを 効果的にするには? 17

  17. 3つの道 18

  18. 第1の道:フローの高速化 19 ▌顧客に価値を届けるフローを高速化する https://itrevolution.com/the-three-ways-principles- underpinning-devops/

  19. 第2の道:フィードバックの強化 20 ▌素早いフィードバックフローの実現 https://itrevolution.com/the-three-ways-principles- underpinning-devops/

  20. 第3の道:継続的な学習と実験 21 ▌フィードバックループの継続的な短縮と強化 https://itrevolution.com/the-three-ways-principles- underpinning-devops/

  21. 第1の道:フローの高速化 22

  22. リリース速度が遅いと? ▌顧客に価値を届けるのが遅れる ▌急激な変化に対応できない ▌1回のリリースにできるかぎり詰め込もうとしてリスクが高まる ⚫ トラブル時に切り戻しづらくなる ⚫ 原因調査も辛い ▌モチベーション的にも辛い 23

  23. WIPの制限 ▌WIP = 進行中の作業、仕掛り ▌完了しないと顧客に提供する価値はゼロ ⚫ 完了とはリリースして顧客からなにかしらのフィードバック が得られるまで ▌マルチタスクは作業効率が落ちる ▌大きな手戻りのリスクが発生する

    ▌他の作業待ちのときに新しい仕事を始めたくなるけど、 それよりも遅れの原因を解決したほうがよい 24
  24. バッチサイズを小さくする ▌バッチサイズが大きいと ⚫ フローが長くなる ⚫ WIPが多くなる ⚫ 問題発生時のリスクが大きい ⚫ 手戻りが大きい

    ⚫ 原因特定が大変 ▌タスクを分割する 25
  25. カンバン ▌作業を可視化して遅れや停滞を把握する 26 https://commons.wikimedia.org/wiki/File:Simple_Task_Kanban.jpg

  26. チーム間の作業の受け渡しを減らす ▌受け渡しが多いと ⚫ 作業が滞留する原因になりがち ⚫ 情報のコンテキストが失われがち ▌チーム間で作業の受け渡しが発生しないようにする ⚫ 自動化 ⚫

    クロスファンクショナルなチーム編成 27
  27. 第2の道:フィードバックの強化 28

  28. フィードバックが遅いと? ▌顧客に発生する問題が大きくなる ▌対応コストが増える 29

  29. 発生と同時に問題を知る ▌自動ビルド、インテグレーション、テスト ▌モニタリング 30

  30. 組織的に問題解決に当たる ▌問題の拡大を防ぐ、学習して再発防止をする ▌トヨタのアンドン 31 https://commons.wikimedia.org/wiki/File:Andon_Otomasyon_Panos u2.jpg

  31. 上流で品質を担保する ▌問題の発見が遅れるほど対応工数が増える ▌後の工程を意識して品質を作り込む ⚫ テストしやすさ ⚫ 運用しやすさ 32

  32. レビューとペアプロ ▌チーム外に承認をもらうプロセスよりもチーム内のレビューの ほうがパフォーマンスが上がりやすい ⚫ タスクに近い人のほうが問題をよく知っている ▌ペアプロは個別に作業したときよりエラーが減るという 研究結果 ⚫ チーム内のノウハウ共有も捗る ▌最近は3人以上のモブプロもよく行われている

    33
  33. 第3の道:継続的な学習と実験 34

  34. 継続的に改善しないと? ▌徐々に問題が増えていく ▌問題が致命的になってから対応すると手遅れになりがち ⚫ 本来のタスクが止まるリスク 35

  35. 失敗を非難しない文化 ▌優秀な組織はそうでない組織よりも多くの失敗を経験している ▌インシデントが発生しても純粋な原因解明と振り返りを行う ⚫ ポストモーテム ▌情報が積極的に共有されるようになる 36

  36. 日常業務を改善する習慣をつくる ▌20%ルール、ハックウィークなど ▌仕事にもっとも近いところにいる人々に問題を継続的に見つけ て改善する権限を与える ▌技術的負債の返済を評価することを示す 37

  37. DevOpsを支える技術的プラクティス 38

  38. 自動化のメリット ▌Consistency ▌Faster Action ▌Time Saving

  39. Consistency ▌人手で複雑な作業手順を繰り返すのは厳しい ▌一貫性のない手順はなにかしらの問題につながる ▌自動化によって一貫性が保たれる

  40. Faster Action ▌機械は人間には不可能なタイミングと速度で実行できる ⚫ 1日1万件のテストも余裕だし24時間365日いつでも大丈夫 ▌問題の早期発見・早期対応はコスト削減につながる

  41. Time Saving ▌コスト削減は自動化で特に強調されるバリュー ▌誰でも実行できるように自動化されるとより効果が高い ▌自動化とそのメンテナンスにもコストはかかるので注意

  42. 自動化のポイント ▌極力人間のActionが入らないようにする ⚫ 人間が実行ボタンを押すよりも特定の操作にフックして実行 する方が望ましいことが多い ▌誰でも使えるようにする ⚫ 利益の最大化 ⚫ 属人化すると負債になりやすい

  43. 自動化する時間がない? ▌自動化しないから時間がない ▌効果を実感しやすいところから少しずつ継続的に改善していく

  44. 自動テスト ▌手動テストが増えると ⚫ デプロイ頻度が下がる ⚫ バッチサイズが大きくなる ▌しかし、手動テストを単純に自動化すればいいというものでは ない ⚫ ソフトウェアに問題がないのにテストが落ちる

    (false positive) 45
  45. テストピラミッド https://watirmelon.blog/testing-pyramids/

  46. 継続的インテグレーション (Continuous Integration) ▌一日に何回もリポジトリにコードをチェックインする ▌毎回テストを含む自動ビルドが実行される

  47. CIのメリット ▌問題の早期発見 ▌頻繁にチェックインされるようになれば差分が大きくならない ⚫ 問題発生時の原因調査が楽 ▌Success/Failの可視化によるコミュニケーション促進 ▌毎回の変更が自動テストで保証される安心感

  48. 49 https://martinfowler.com/bliki/ContinuousIntegrationCertification.html

  49. 継続的デリバリー (Continuous Delivery) ▌CIの発展形 ▌常に信頼できるリリースができる状態を保つ ▌リリースに必要な検証をデリバリーパイプラインで実現する

  50. https://en.wikipedia.org/wiki/Continuous_delivery

  51. 継続的デリバリーのメリット ▌ビジネス側の都合のいいタイミングでリリースできる ▌リリースのコストやリスクを抑える ▌リリースまでのフローがパイプラインで可視化される ⚫ どこで問題が起きているかもすぐ分かる

  52. リリースとデプロイの分離 ▌デプロイ:指定された環境に指定されたバージョンのソフト ウェアをインストールすること ▌リリース:すべての顧客、または一部の顧客に対して機能を利 用可能な状態にすること ▌デプロイは開発と運用の責任、リリースはビジネス側の責任

  53. ブルーグリーンデプロイメント https://martinfowler.com/bliki/BlueGreenDeployment.ht ml

  54. カナリアリリース https://martinfowler.com/bliki/CanaryRelease.html

  55. まとめ 56

  56. これから ▌共通のビジネスゴール達成のために3つの道を進んでいく ⚫ フローの高速化 ⚫ フィードバックの強化 ⚫ 継続的な学習と実験 ▌講義で話したことはごく一部 ⚫

    業務をする上でもっと知りたくなってきたら参考資料を 読んでみてください 57
  57. 参考資料 ▌『The DevOps ハンドブック 理論・原則・実践のすべて』 ▌『Site Reliability Engineering』 ▌『継続的デリバリー』 58