Slide 1
Slide 1 text
DevOps 実装者としての
SRE の存在と役割
JDDStudy #3
@katsuhisa__ / 北野勝久
Copyright (C) 2018 Studist Corporation. All Rights Reserved
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__