DevOps実装者としてのSREの存在と役割

JDDStudy #3 (https://techplay.jp/event/687946) で発表した資料です。
DevOpsとSREとの関係性、どのようなことを実践・実装するかの具体例を話しました。

Transcript

1. DevOps 実装者としての SRE の存在と役割 JDDStudy #3 @katsuhisa__ / 北野勝久 Copyright (C) 2018 Studist Corporation. All Rights Reserved
2. #JDDStudy
3. • 北野 勝久 / @katsuhisa__ • SRE @ Studist Corporation • Organizer of SRE Lounge / Rails Developers Meetup • Developers Summit, / July Tech Festa 登壇 etc. • Linux カーネルと同い年
4. マニュアル作成・共有プラットフォーム
6. 勉強会のテーマ JDDStudy #3 最新DevOps事例勉強会！ スタートアップとグロースフェーズ それぞれの開発チームが取り組むDevOpsの今。
7. Teachme Biz はグロースフェーズ
8. 2016年 数 千ユーザー増 2018年 数 万ユーザー増 月間ユーザー増加ペース
9. 2016年 3 2018年 18 開発チーム
10. 本日お話すること・目的 • 「サービス」「チーム」がスケールするために DevOpsを実践・実装してきた歴史 ◦ SREチームとしての活動中心に ◦ それ以外の話も • DevOpsをどうやって始めればよいかのヒント
11. Agenda • 自己紹介 • お話することの紹介 • DevOps? SRE? • DevOps実践・実装の歴史 • まとめ
12. CHAPTER 1 How SRE Relates to DevOps class SRE implements interface DevOps 『The Site Reliability Workbook』 ※日本語訳発売時期未定
13. DevOps is a broad set of principles about whole-lifecycle collaboration between operations and product development. SRE is a job role, a set of practices we’ve found to work, and some beliefs that animate those practices. 『The Site Reliability Workbook 』より引用
14. If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes, and is somewhat closer to a concrete definition of a job or role than, say, “DevOps engineer.” So, in a way, class SRE implements interface DevOps. Given that trajectory, the discipline as a whole currently does not foreground cultural change by default quite as much as DevOps. 『The Site Reliability Workbook 』より引用
15. まとめると・・・ 　DevOps 　　Dev, Ops, その他チーム全体を巻き込み、 　　一体で仕事を進めるための文化運動であり方法 　SRE 　　ソフトウェアエンジニアがOps を設計する際の 　　プラクティスであり、DevOpsを実装する役割 　　DevOpsほど文化的変化を前提としない
16. 詳しくは・・・ 私がCodeZineさんに 寄稿している SREの連載をぜひ！ https://codezine.jp/article/detail/11002
17. Agenda • 自己紹介 • お話することの紹介 • DevOps? SRE? • DevOps実践・実装の歴史 • まとめ
18. アンチパターンの塊だった過去
19. ブラックボックス地獄 • サーバー内変更作業は、 手作業＆ドキュメントなし • 毎日が新しい発見
20. OSパッチ適用地獄 • Immutable でない＆構成管理手作業のため、 作業前に毎回マシンイメージのバックアップ ◦ もちろん手作業 ◦ サーバ種別ごとに毎回ぽちぽち
21. 障害調査地獄 • モニタリングが貧弱 ◦ 調査以前に把握がつらい • 直前デプロイを疑うも、 原因はまったく別のところだった
22. サービスもチームも スケールできない危機感
23. DevOps実践・実装してきたこと • 三大地獄を乗り越えるために • サービスのスケールのために • チームのスケールのために
24. DevOps実践・実装してきたこと • 三大地獄を乗り越えるために • サービスのスケールのために • チームのスケールのために
25. VS. ブラックボックス地獄 • インフラをコード化 ◦ 2週間かけて、全環境AnsibleのPlaybook化 • GitHub でコードのバージョン管理 ◦ Pull Request ベースで仕事できるの大事 • テスト駆動で開発できるようにServerspec導入
26. インフラもバージョン管理しような って書いてるレポート The benefits of version control shouldn’t be limited to application code; in fact, our analysis shows that organizations using version control for both system and application configurations have higher IT performance. （職場で、エライ人に何か言われた時のための理論武装としてどうぞ） https://puppet.com/resources/whitepaper/2014-state-devops-report
27. VS. OSパッチ適用地獄 • Immutable Infrastructure にした ◦ AMIバックアップの手間から解放 • マシンイメージのビルドは、 Pull Request merge 時に自動実行 or 1クリック • Terraform も導入中 [WIP] ◦ 全行程が自動 or 1クリックで完了するように
28. AWS DevOps Blog
29. AWS DevOps Blog 　CodeBuild 上で実行させることで、 - ローカルPC のネットワークが切れてもOK - 実行履歴が常に残る
30. VS. 障害調査地獄 • モニタリング基盤を新しくつくった ◦ Elasticsearch/Kibana ◦ ここを見れば、サービスの状態が分かる • アラート再設計 ◦ モニタリングで得られるアウトプットを分類 ▪ ALERTS, TICKETS, LOGGING ◦ 不足している監視項目を新規実装
31. DevOps実践・実装してきたこと • 三大地獄を乗り越えるために • サービスのスケールのために • チームのスケールのために
32. Production Readiness Review • 開発された成果物 / 設計の 信頼性に関するレビュー • Hand-off Readiness Review • Launch Readiness Review
33. SRE＠Google： Thousands of DevOps Since 2004 https://www.youtube.com/ watch?v=iIuTnhdTzK0
34. SRE＠Google： Thousands of DevOps Since 2004 https://www.youtube.com/ watch?v=iIuTnhdTzK0 Google が実践している サービスハンドブック（差し戻し）
35. DevOps実践・実装してきたこと • 三大地獄を乗り越えるために • サービスのスケールのために • チームのスケールのために
36. チームのスケールのために • ラーニングカルチャーをつくる ◦ 社内勉強会の開催 ◦ 社外勉強会への参加奨励 ◦ 振り返り部 ◦ ポストモーテム ◦ （番外編）Twitter は仕事 を体現する
37. ChatOpsで、 社内勉強会ネタを ストック /todo AWS基礎
38. 社内勉強会、社外勉強会の アウトプットをチームで共有
39. 社内勉強会、社外勉強会の アウトプットをチームで共有 勉強会参加は、業務時間で 参加費は補助 遠方の勉強会参加時は、交通費も補助
40. 振り返り部 • 有志で、開発チームをまたいだ振り返りを実践 • 同じチーム内の振り返りで、 扱う機会の少ないトピックを取り扱う ◦ 開発組織全般 ◦ 個人の働き方や成長
41. 振り返り部 • 有志で、開発チームをまたいだ振り返りを実践 • 同じチーム内の振り返りで、 扱う機会の少ないトピックを取り扱う ◦ 開発組織全般 ◦ 個人の働き方や成長 Career KPT を 今後やっていく予定
42. ポストモーテム • 障害振り返り • 非難をしない • 新しく入ってきたメンバーと読み合わせし、 失敗から学習する文化を共有する
43. (番外編) Twitter は仕事 を体現する • 自社内だけでの情報のやり取りに閉じるより、 社外とも行われる方が良い • Twitter での情報収集が、 開発の意思決定材料になることは日常茶飯事 • よって、Twitter は仕事
45. Agenda • 自己紹介 • お話することの紹介 • DevOps? SRE? • DevOps実践・実装の歴史 • まとめ
46. DevOps 3つの道
47. 1. フロー改善 2. フィードバック 3. 継続的な学習と実験
48. 「今日お話した内容は、いずれかに当てはまる」 と言うと、驚かれる方も多いのでは？
49. いいえ、ちゃんと書籍にも書いてます
50. DevOps のはじめかた • 固定概念をやめる • チームみんなで楽しく仕事し続けることを 大真面目に考える • 自分の役割範囲外の発言や行動も DevOps の実践につながると心得る
51. よいDevOpsライフを IaC やMonitoring など 技術的なことで分からないことがあれば、 いつでもご連絡ください @katsuhisa__