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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#JDDStudy

Slide 3

Slide 3 text

● 北野勝久 / @katsuhisa__ ● SRE @ Studist Corporation ● Organizer of SRE Lounge / Rails Developers Meetup ● Developers Summit, / July Tech Festa 登壇 etc. ● Linux カーネルと同い年

Slide 4

Slide 4 text

マニュアル作成・共有プラットフォーム

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

勉強会のテーマ JDDStudy #3 最新DevOps事例勉強会！スタートアップとグロースフェーズそれぞれの開発チームが取り組むDevOpsの今。

Slide 7

Slide 7 text

Teachme Biz はグロースフェーズ

Slide 8

Slide 8 text

2016年数千ユーザー増 2018年数万ユーザー増月間ユーザー増加ペース

Slide 9

Slide 9 text

2016年 3 2018年 18 開発チーム

Slide 10

Slide 10 text

本日お話すること・目的 ● 「サービス」「チーム」がスケールするために DevOpsを実践・実装してきた歴史 ○ SREチームとしての活動中心に ○ それ以外の話も ● DevOpsをどうやって始めればよいかのヒント

Slide 11

Slide 11 text

Agenda ● 自己紹介 ● お話することの紹介 ● DevOps? SRE? ● DevOps実践・実装の歴史 ● まとめ

Slide 12

Slide 12 text

CHAPTER 1 How SRE Relates to DevOps class SRE implements interface DevOps 『The Site Reliability Workbook』 ※日本語訳発売時期未定

Slide 13

Slide 13 text

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 』より引用

Slide 14

Slide 14 text

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 』より引用

Slide 15

Slide 15 text

まとめると・・・　DevOps 　　Dev, Ops, その他チーム全体を巻き込み、　　一体で仕事を進めるための文化運動であり方法　SRE 　　ソフトウェアエンジニアがOps を設計する際の　　プラクティスであり、DevOpsを実装する役割　　DevOpsほど文化的変化を前提としない

Slide 16

Slide 16 text

詳しくは・・・私がCodeZineさんに寄稿している SREの連載をぜひ！ https://codezine.jp/article/detail/11002

Slide 17

Slide 17 text

Agenda ● 自己紹介 ● お話することの紹介 ● DevOps? SRE? ● DevOps実践・実装の歴史 ● まとめ

Slide 18

Slide 18 text

アンチパターンの塊だった過去

Slide 19

Slide 19 text

ブラックボックス地獄 ● サーバー内変更作業は、手作業＆ドキュメントなし ● 毎日が新しい発見

Slide 20

Slide 20 text

OSパッチ適用地獄 ● Immutable でない＆構成管理手作業のため、作業前に毎回マシンイメージのバックアップ ○ もちろん手作業 ○ サーバ種別ごとに毎回ぽちぽち

Slide 21

Slide 21 text

障害調査地獄 ● モニタリングが貧弱 ○ 調査以前に把握がつらい ● 直前デプロイを疑うも、原因はまったく別のところだった

Slide 22

Slide 22 text

サービスもチームもスケールできない危機感

Slide 23

Slide 23 text

DevOps実践・実装してきたこと ● 三大地獄を乗り越えるために ● サービスのスケールのために ● チームのスケールのために

Slide 24

Slide 24 text

DevOps実践・実装してきたこと ● 三大地獄を乗り越えるために ● サービスのスケールのために ● チームのスケールのために

Slide 25

Slide 25 text

VS. ブラックボックス地獄 ● インフラをコード化 ○ 2週間かけて、全環境AnsibleのPlaybook化 ● GitHub でコードのバージョン管理 ○ Pull Request ベースで仕事できるの大事 ● テスト駆動で開発できるようにServerspec導入

Slide 26

Slide 26 text

インフラもバージョン管理しようなって書いてるレポート 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

Slide 27

Slide 27 text

VS. OSパッチ適用地獄 ● Immutable Infrastructure にした ○ AMIバックアップの手間から解放 ● マシンイメージのビルドは、 Pull Request merge 時に自動実行 or 1クリック ● Terraform も導入中 [WIP] ○ 全行程が自動 or 1クリックで完了するように

Slide 28

Slide 28 text

AWS DevOps Blog

Slide 29

Slide 29 text

AWS DevOps Blog 　CodeBuild 上で実行させることで、 - ローカルPC のネットワークが切れてもOK - 実行履歴が常に残る

Slide 30

Slide 30 text

VS. 障害調査地獄 ● モニタリング基盤を新しくつくった ○ Elasticsearch/Kibana ○ ここを見れば、サービスの状態が分かる ● アラート再設計 ○ モニタリングで得られるアウトプットを分類 ■ ALERTS, TICKETS, LOGGING ○ 不足している監視項目を新規実装

Slide 31

Slide 31 text

DevOps実践・実装してきたこと ● 三大地獄を乗り越えるために ● サービスのスケールのために ● チームのスケールのために

Slide 32

Slide 32 text

Production Readiness Review ● 開発された成果物 / 設計の信頼性に関するレビュー ● Hand-off Readiness Review ● Launch Readiness Review

Slide 33

Slide 33 text

SRE＠Google： Thousands of DevOps Since 2004 https://www.youtube.com/ watch?v=iIuTnhdTzK0

Slide 34

Slide 34 text

SRE＠Google： Thousands of DevOps Since 2004 https://www.youtube.com/ watch?v=iIuTnhdTzK0 Google が実践しているサービスハンドブック（差し戻し）

Slide 35

Slide 35 text

DevOps実践・実装してきたこと ● 三大地獄を乗り越えるために ● サービスのスケールのために ● チームのスケールのために

Slide 36

Slide 36 text

チームのスケールのために ● ラーニングカルチャーをつくる ○ 社内勉強会の開催 ○ 社外勉強会への参加奨励 ○ 振り返り部 ○ ポストモーテム ○ （番外編）Twitter は仕事を体現する

Slide 37

Slide 37 text

ChatOpsで、社内勉強会ネタをストック /todo AWS基礎

Slide 38

Slide 38 text

社内勉強会、社外勉強会のアウトプットをチームで共有

Slide 39

Slide 39 text

社内勉強会、社外勉強会のアウトプットをチームで共有勉強会参加は、業務時間で参加費は補助遠方の勉強会参加時は、交通費も補助

Slide 40

Slide 40 text

振り返り部 ● 有志で、開発チームをまたいだ振り返りを実践 ● 同じチーム内の振り返りで、扱う機会の少ないトピックを取り扱う ○ 開発組織全般 ○ 個人の働き方や成長

Slide 41

Slide 41 text

振り返り部 ● 有志で、開発チームをまたいだ振り返りを実践 ● 同じチーム内の振り返りで、扱う機会の少ないトピックを取り扱う ○ 開発組織全般 ○ 個人の働き方や成長 Career KPT を今後やっていく予定

Slide 42

Slide 42 text

ポストモーテム ● 障害振り返り ● 非難をしない ● 新しく入ってきたメンバーと読み合わせし、失敗から学習する文化を共有する

Slide 43

Slide 43 text

(番外編) Twitter は仕事を体現する ● 自社内だけでの情報のやり取りに閉じるより、社外とも行われる方が良い ● Twitter での情報収集が、開発の意思決定材料になることは日常茶飯事 ● よって、Twitter は仕事

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Agenda ● 自己紹介 ● お話することの紹介 ● DevOps? SRE? ● DevOps実践・実装の歴史 ● まとめ

Slide 46

Slide 46 text

DevOps 3つの道

Slide 47

Slide 47 text

1. フロー改善 2. フィードバック 3. 継続的な学習と実験

Slide 48

Slide 48 text

「今日お話した内容は、いずれかに当てはまる」と言うと、驚かれる方も多いのでは？

Slide 49

Slide 49 text

いいえ、ちゃんと書籍にも書いてます

Slide 50

Slide 50 text

DevOps のはじめかた ● 固定概念をやめる ● チームみんなで楽しく仕事し続けることを大真面目に考える ● 自分の役割範囲外の発言や行動も DevOps の実践につながると心得る

Slide 51

Slide 51 text

よいDevOpsライフを IaC やMonitoring など技術的なことで分からないことがあれば、いつでもご連絡ください @katsuhisa__