Slide 1
Slide 1 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOpsを実現するSREの存在意義と役割
class SRE implements NoOps
株式会社スタディスト 北野 勝久
NoOps Meetup #6 2019/06/04
Slide 2
Slide 2 text
Copyright © 2019 Studist Corporation. All Rights Reserved
#NoOpsJP
イベントハッシュタグ
Slide 3
Slide 3 text
Copyright © 2019 Studist Corporation. All Rights Reserved
北野 勝久 / @katsuhisa__
Katsuhisa Kitano
株式会社スタディスト 開発部 SRE
Linux カーネルと同い年
Organizer of SRE Lounge
Developers Summit 登壇 etc...
Slide 4
Slide 4 text
Copyright © 2019 Studist Corporation. All Rights Reserved
“伝えることを、もっと簡単に。”
https://studist.jp/
会社紹介
Slide 5
Slide 5 text
Copyright © 2019 Studist Corporation. All Rights Reserved
サービス紹介
Slide 6
Slide 6 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps とは一体なんだったのか
STEP 1
SRE と NoOps
STEP 2
Eliminating Toil at Studist
STEP 3
Agenda
Slide 7
Slide 7 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps とは一体なんだったのか
STEP 1
SRE と NoOps
STEP 2
Eliminating Toil at Studist
STEP 3
Agenda
Slide 8
Slide 8 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps とは
Slide 9
Slide 9 text
Copyright © 2019 Studist Corporation. All Rights Reserved
フォレスター・リサーチ社のレポート（2011/4）
https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203
Slide 10
Slide 10 text
Copyright © 2019 Studist Corporation. All Rights Reserved
フォレスター・リサーチ社のレポート（2011/4）
https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203
A DevOps focus on collaboration evolves into
a NoOps focus on automation.
But there is no magic — in this ambitious NoOps future,
operations professionals must utilize infrastructure,
working differently to enable developers to achieve better outcomes
with less manual intervention.
Slide 11
Slide 11 text
Copyright © 2019 Studist Corporation. All Rights Reserved
フォレスター・リサーチ社のブログ（2011/2）
https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/
Slide 12
Slide 12 text
Copyright © 2019 Studist Corporation. All Rights Reserved
フォレスター・リサーチ社のブログ（2011/2）
https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/
The goal of NoOps is also to improve the process of deploying applications.
But, NoOps means that application developers
will never have to speak with an operations professional again.
Slide 13
Slide 13 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Netflix のエンジニアのブログ（2012/3）
http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html
Slide 14
Slide 14 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Netflix のエンジニアのブログ（2012/3）
http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html
There is no ops organization involved in running our cloud,
no need for the developers
to interact with ops people to get things done,
and less time spent actually doing ops tasks
than developers would spend explaining what needed to be done to someone else.
Slide 15
Slide 15 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Netflix のエンジニアのブログへ言及したドキュメント（2012/3）
https://gist.github.com/jallspaw/2140086
Slide 16
Slide 16 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Netflix のエンジニアのブログへ言及したドキュメント（2012/3）
https://gist.github.com/jallspaw/2140086
Like many have pointed out,
the issue people have with "NoOps" is the presence of "No" in it.
This is because you (and others) are intermingling titles
(and therefore organizational groups) with
the often blurred domain expertise usually (but not evenly-distributed across
a diverse spectrum of organizations) associated with Operations.
Slide 17
Slide 17 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps について僕が知っていること
● 2011 年に調査会社 フォレスター・リサーチ社が「NoOps」を提唱
○ コラボレーションを重視するDevOps に対し
自動化をより重視する NoOps という概念構造
■ 一部の Ops 業務にて
Dev と Ops はコミュニケーションする必要がなくなる世界観
● 一部の従来の Ops 業務に人間が介在しない状態を NoOps と捉え
Netflix のエンジニアが事例共有
● そのブログへの批判をした gist が話題に
○ > Regardless, you're still doing what almost everyone I know would call "Ops".
Slide 18
Slide 18 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps の一連の話題について僕が思うこと
● NoOps の “Ops” を職種や役割と捉え、理解しようとすると拒否反応が出る
○ Ops を一連の業務群だと捉えると、
一部をソフトウェアで行うことはごく自然なこと
● どこまでを Ops と捉えるかの解釈がズレると
議論がちゃんとできない
○ 「その業務を Ops のお仕事だとすると No にできなくね？」
⇒認知の離散化が起きないように議論しよう
Slide 19
Slide 19 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps の一連の話題について僕が思うこと
● NoOps の “Ops” を職種や役割と捉え、理解しようとすると拒否反応が出る
○ Ops を一連の業務群だと捉えると、
一部をソフトウェアで行うことはごく自然なこと
● どこまでを Ops と捉えるかの解釈がズレると
議論がちゃんとできない
○ 「その業務を Ops のお仕事だとすると No にできなくね？」
⇒認知の離散化が起きないように議論しよう
NoOps Japan 発起人の岡さんが
「No "Uncomfortable" Ops」と提唱しているのも
このへんの背景があるはず
Slide 20
Slide 20 text
Copyright © 2019 Studist Corporation. All Rights Reserved
岡さんが提唱する 「No "Uncomfortable" Ops」 の内訳
https://www.slideshare.net/hiromasaoka/15-noops
Slide 21
Slide 21 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps !=
No Operations
Slide 22
Slide 22 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps とは一体なんだったのか
STEP 1
SRE と NoOps
STEP 2
Eliminating Toil at Studist
STEP 3
Agenda
Slide 23
Slide 23 text
Copyright © 2019 Studist Corporation. All Rights Reserved
https://landing.google.com/sre/books/
Slide 24
Slide 24 text
Copyright © 2019 Studist Corporation. All Rights Reserved
SRE？
My explanation is simple:
SRE is what happens when you ask a software engineer
to design an operations team.
https://landing.google.com/sre/sre-book/chapters/introduction/
Slide 25
Slide 25 text
Copyright © 2019 Studist Corporation. All Rights Reserved
SRE と NoOps
● SRE では、「No "Uncomfortable" Ops」に相当する文脈として
「Eliminating Toil」がある
Slide 26
Slide 26 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Toil？
In SRE, we want to spend time on long-term engineering project work
instead of operational work.
Because the term operational work may be misinterpreted,
we use a specific word: toil.
〜（中略）〜
So what is toil?
Toil is the kind of work tied to running a production service that
tends to be manual, repetitive, automatable, tactical,
devoid of enduring value, and that scales linearly as a service grows.
https://landing.google.com/sre/sre-book/chapters/eliminating-toil/
Slide 27
Slide 27 text
Copyright © 2019 Studist Corporation. All Rights Reserved
SRE と Toil
SRE は Toil を業務時間の 50% 以下におさえる
⇒ どうやって Toil を撲滅する？そもそも Toil をどうやって計測する？
Slide 28
Slide 28 text
Copyright © 2019 Studist Corporation. All Rights Reserved
NoOps とは一体なんだったのか
STEP 1
SRE と NoOps
STEP 2
Eliminating Toil at Studist
STEP 3
Agenda
Slide 29
Slide 29 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Eliminating Toil at
Studist SRE Team
Slide 30
Slide 30 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Toil の計測
Slide 31
Slide 31 text
Copyright © 2019 Studist Corporation. All Rights Reserved
SRE の業務を分類する（ SRE Book の教え）
1. Software engineering
- 設計、ドキュメンテーションに加えコードの作成や変更
2. Systems engineering
- 本番システムの構成の変更（OSパラメータの調整、ロードバランサ設定等）
3. Toil
- 反復的、手動などのサービスの実行に直接関係する作業
4. Overhead
- 採用業務、チーム/会社の会議、トレーニングなど
https://landing.google.com/sre/sre-book/chapters/eliminating-toil/
Slide 32
Slide 32 text
Copyright © 2019 Studist Corporation. All Rights Reserved
スタディストでの業務分類
1. OKR Work
- OKR 達成に関連するタスク
2. Project Work
- Issue ベースで取り組まなければならないタスク
3. Toil
- 反復的、手動などのサービスの実行に直接関係する作業
4. Overhead
- 採用業務、チーム/会社の会議、トレーニングなど
Slide 33
Slide 33 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Team Monitoring at Studist SRE Team
● KANNBAN に先ほどの分類ごとにレーンを設け、タスク管理
● すべての業務にポイントを付与
○ ポイント≒業務に要する時間の目安
● 週の終わりに、業務のポイントの割合を計測
○ Toil に要した時間や、OKR に集中できた時間を可視化
● （余談）戦略的に取り組むタスクは Backlog で管理し、優先度づけ
○ Toil や Overhead は Backlog には入れず、
発生都度ポイントを付与し、KANNBAN にタスク追加
Slide 34
Slide 34 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Team Monitoring at Studist SRE Team
● KANNBAN に先ほどの分類ごとにレーンを設け、タスク管理
● すべての業務にポイントを付与
○ ポイント≒業務に要する時間の目安
● 週の終わりに、業務のポイントの割合を計測
○ Toil に要した時間や、OKR に集中できた時間を可視化
● （余談）戦略的に取り組むタスクは Backlog で管理し、優先度づけ
○ Toil や Overhead は Backlog には入れず、
発生都度ポイントを付与し、KANNBAN にタスク追加
ベロシティも計測しているが、
作業時間割合の計測をより重視
⇒ チームの時間の使い方の健全性を維持
⇒ 今期の Toil の割合は、 5%〜10% を推移
Slide 35
Slide 35 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Team Monitoring at Studist SRE Team
● KANNBAN に先ほどの分類ごとにレーンを設け、タスク管理
● すべての業務にポイントを付与
○ ポイント≒業務に要する時間の目安
● 週の終わりに、業務のポイントの割合を計測
○ Toil に要した時間や、OKR に集中できた時間を可視化
● （余談）戦略的に取り組むタスクは Backlog で管理し、優先度づけ
○ Toil や Overhead は Backlog には入れず、
発生都度ポイントを付与し、KANNBAN にタスク追加
ベロシティも計測しているが、
作業時間割合の計測をより重視
⇒ チームの時間の使い方の健全性を維持
⇒ 今期の Toil の割合は、 5%〜10% を推移
昔は、 Toil まみれだった
どうやってここにたどり着いたか？
Slide 36
Slide 36 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Toil Management Strategies
Slide 37
Slide 37 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Toil Management Strategies（SRE Workbook の教え）
● Promote Toil Reduction as a Feature
● Start Small and Then Improve
● Increase Uniformity
● Assess Risk Within Automation
● Automate Toil Response
● Use Open Source and Third-Party Tools
● Use Feedback to Improve
● Identify and Measure Toil
● Engineer Toil Out of the System
● Reject the Toil
● Use SLOs to Reduce Toil
● Start with
Human-Backed Interfaces
● Provide Self-Service Methods
● Get Support from
Management and Colleagues https://landing.google.com/sre/workbook/chapters/eliminating-toil/
Slide 38
Slide 38 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Engineer Toil Out of the System
Use SLOs to Reduce Toil
Eliminating Toil at Studist SRE Team
Provide Self-Service Methods
1
2
3
Slide 39
Slide 39 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Engineer Toil Out of the System
Use SLOs to Reduce Toil
Eliminating Toil at Studist SRE Team
Provide Self-Service Methods
1
2
3
Slide 40
Slide 40 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Engineer Toil Out of the System
● Toil を減らすためには、そもそも Toil が生まれないようなシステムにする
● 既存のシステムにおける Toil を減らすことに投資する前に、
システムを変えられないか？を考える
● また、新しくつくるシステムやコンポーネントを、
Toil が生まれにくいようにする
Slide 41
Slide 41 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Design Document を書く
Slide 42
Slide 42 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Design Document を書く
● 不可逆性の高い部分はどこか？
● 性能面で詰まる可能性が高い部分はどこか？
● なぜ、その設計だとダメなのか？
● Design Document は必ず書く
● Postmortem を書くのと同じくらい重視
● 障害を収束させた人間より、
障害を生まなかった人間を評価したい
Slide 43
Slide 43 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Design Document を書く
● 不可逆性の高い部分はどこか？
● 性能面で詰まる可能性が高い部分はどこか？
● なぜ、その設計だとダメなのか？
● Design Document は必ず書く
● Postmortem を書くのと同じくらい重視
● 障害を収束させた人間より、
障害を生まなかった人間を評価したい
評価フィードバックの場や、
常日頃のコミュニケーションでも
デザインドキュメントの重要性を
チームに繰り返し語る
Slide 44
Slide 44 text
Copyright © 2019 Studist Corporation. All Rights Reserved
より信頼性の高いコンポーネントに置き換える
https://speakerdeck.com/katsuhisa91/db-an-hao-hua-woyaretoyan-waretakedo-aurora-yi-xing-wotong-shi-nishi-xian-sitahua
Slide 45
Slide 45 text
Copyright © 2019 Studist Corporation. All Rights Reserved
より信頼性の高いコンポーネントに置き換える
https://speakerdeck.com/katsuhisa91/db-an-hao-hua-woyaretoyan-waretakedo-aurora-yi-xing-wotong-shi-nishi-xian-sitahua
● なぜ信頼性が高いのかをハラオチする
● マネージドサービスであっても、
公開情報から内部構造を知ることができる場合も多い
● Aurora の場合は、以下論文など
Amazon Aurora: Design Considerations
for High Throughput Cloud-Native Relational Databases
http://dl.acm.org/citation.cfm?id=3056101
Slide 46
Slide 46 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Engineer Toil Out of the System
Use SLOs to Reduce Toil
Eliminating Toil at Studist SRE Team
Provide Self-Service Methods
1
2
3
Slide 47
Slide 47 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Use SLOs to Reduce Toil
● SLO？
○ 稼働率 100% ではなく、 99.9% のようにダウンタイムを許容する
■ != SLA
● 過剰にダウンタイムを高めようとすることは、
他のタスクにかける時間を必要以上に失う
○ 98点→99点の労力は、80点→90点の労力より大きい
○ SLO を定義しておくことで、
必要以上の性能目標を目指し Toil が膨張しすぎることを防ぐ
Slide 48
Slide 48 text
Copyright © 2019 Studist Corporation. All Rights Reserved
スタディストにおける SLO の活用
Slide 49
Slide 49 text
Copyright © 2019 Studist Corporation. All Rights Reserved
スタディストにおける SLO の活用
● 性能面に先手を打つことで、
新たな Toil が生まれないようにする
● チームの協力があってこそ運用できているので、
チームのみんなには本当に感謝
Slide 50
Slide 50 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Engineer Toil Out of the System
Use SLOs to Reduce Toil
Eliminating Toil at Studist SRE Team
Provide Self-Service Methods
1
2
3
Slide 51
Slide 51 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Provide Self-Service Methods
● 開発者から依頼を受けて仕事をするのではなく、
開発者自身にやってもらえるようにする
● チケットドリブンでの仕事は、組織の経済的な無駄を生む
Slide 52
Slide 52 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Ticket-Driven Request Queues Are Expensive
The Principles of Product Development Flow
https://www.amazon.co.jp/dp/B007TKU0O0/
Slide 53
Slide 53 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Envoy 開発者 Matt の DevOps 定義
DevOps is the practice of developers being responsible for
operating their services in production, 24/7.
This includes development using shared infrastructure primitives, testing, on-call,
reliability engineering, disaster recovery, defining SLOs, monitoring setup and alarming,
debugging and performance analysis, incident root cause analysis,
provisioning and deployment, etc.
The human scalability of “DevOps”
https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a
Slide 54
Slide 54 text
Copyright © 2019 Studist Corporation. All Rights Reserved
“Operate what you build” puts the devops principles in action by having the team
that develops a system also be responsible for operating and supporting that system.
Distributing this responsibility to each development team, rather than externalizing it,
creates direct feedback loops and aligns incentives.
Teams that feel operational pain are empowered to remediate the pain
by changing their system design or code;
they are responsible and accountable for both functions.
Full Cycle Developers at Netflix — Operate What You Build
https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249
Full Cycle Developer @ Netflix
Slide 55
Slide 55 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Self-Service を構成する 3つの要素
Self-Service Operations
https://www.rundeck.com/self-service
Slide 56
Slide 56 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Traditional Ops Silo
Self-Service Operations
https://www.rundeck.com/self-service
Slide 57
Slide 57 text
Copyright © 2019 Studist Corporation. All Rights Reserved
“Rigid” Self-Service
Self-Service Operations
https://www.rundeck.com/self-service
Slide 58
Slide 58 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Self-Service
Self-Service Operations
https://www.rundeck.com/self-service
Slide 59
Slide 59 text
Copyright © 2019 Studist Corporation. All Rights Reserved
AWS Organization を活用した Governance 構築
● AWS Organization を活用し、 Governance を構築する
○ 開発者自身で必要なものを考え
自分たちで構築できるように AWS の権限を付与
○ 一方、単なる権限付与では、 Governance 構築は不十分
Slide 60
Slide 60 text
Copyright © 2019 Studist Corporation. All Rights Reserved
スタディストにおける AWS アカウント分割の考え方
●
AWS Organization
Admin OU Service OU
Sandbox OU
Admin
Audit
Prod Prod-Backup Stg
Sandbox
全監査ログ
保管
アカウント
管理
Production Backup を
保管
Staging
Sandbox
※ OU = Organizational Unit
Slide 61
Slide 61 text
Copyright © 2019 Studist Corporation. All Rights Reserved
スタディストにおける AWS アカウント分割の考え方
●
AWS Organization
Admin OU Service OU
Sandbox OU
Admin
Audit
Prod Prod-Backup Stg
Sandbox
全監査ログ
保管
AWS
アカウント管理
Production Backup を
保管
Staging
Sandbox
● AWS 権限を与えるだけでなく
ドキュメントを整備し、必要な情報を提供
○ まだまだドキュメントは足りていない
● 今後やること
○ Terraform で必要な環境を構築する template 整備
○ SRE チームへの留学制度運用
■ インフラ系のノウハウを開発者と共有する
※ OU = Organizational Unit
Slide 62
Slide 62 text
Copyright © 2019 Studist Corporation. All Rights Reserved
デプロイの責務を開発者に移管
AWS CodePipeline がトリガーされる
STEP 2
AWS CodeBuild でアセットプリコンパイル
STEP 3
Production 同等環境にデプロイされ、最終動作確認ができる
※社内からのみアクセス可
STEP 4
問題なければ、承認ボタンを押し、 Production にデプロイ
STEP 5
GitHub で対象 Pull Request を master にマージ
STEP 1
Slide 63
Slide 63 text
Copyright © 2019 Studist Corporation. All Rights Reserved
デプロイの責務を開発者に移管
AWS CodePipeline がトリガーされる
STEP 2
AWS CodeBuild でアセットプリコンパイル
STEP 3
Production 同等環境にデプロイされ、最終動作確認ができる
※社内からのみアクセス可
STEP 4
問題なければ、承認ボタンを押し、 Production にデプロイ
STEP 5
GitHub で対象 Pull Request を master にマージ
STEP 1
● 2人以上の Approve 必須
● 前提として CircleCI でのテスト実行
Slide 64
Slide 64 text
Copyright © 2019 Studist Corporation. All Rights Reserved
デプロイの責務を開発者に移管
AWS CodePipeline がトリガーされる
STEP 2
AWS CodeBuild でアセットプリコンパイル
STEP 3
Production 同等環境にデプロイされ、最終動作確認ができる
※社内からのみアクセス可
STEP 4
問題なければ、承認ボタンを押し、 Production にデプロイ
STEP 5
GitHub で対象 Pull Request を master にマージ
STEP 1
デプロイ後に Production で
問題が起きれば、
1クリックでロールバック
Slide 65
Slide 65 text
Copyright © 2019 Studist Corporation. All Rights Reserved
デプロイの責務を開発者に移管
AWS CodePipeline がトリガーされる
STEP 2
AWS CodeBuild でアセットプリコンパイル
STEP 3
Production 同等環境にデプロイされ、最終動作確認ができる
※社内からのみアクセス可
STEP 4
問題なければ、承認ボタンを押し、 Production にデプロイ
STEP 5
GitHub で対象 Pull Request を master にマージ
STEP 1
デプロイ後に Production で
問題が起きれば、
1クリックでロールバック
Slide 66
Slide 66 text
Copyright © 2019 Studist Corporation. All Rights Reserved
開発者による問題検知を促進するモニタリング基盤
● 性能的な問題検知
○ Stackdriver による Uptime Check でレイテンシを計測
○ 非同期処理に関しても、ジョブキューの滞留状況を計測
○ NewRelic で Apdex の監視
● 機能的な問題検知
○ NewRelic でエラーレートの監視
○ Stackdriver Error Reporting で、新着エラーをアラート
● 分析基盤
○ fluentd でログを Elasticsearch/Kibana に集約
Slide 67
Slide 67 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Stackdriver カスタムメトリクスを活用したジョブキューの可視化
●
Slide 68
Slide 68 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Stackdriver カスタムメトリクスを活用したジョブキューの可視化
●
● 実際の処理がない空ジョブを定期的にキューに入れ、
「キューに突っ込む時間」と「実際に処理された時間」の差分を
Stackdriver のカスタムメトリクスとしてポストし、可視化
● キュー内のジョブ滞留時間が長くなると、アラート
Slide 69
Slide 69 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Stackdriver Error Reporting による新着バグ検知
> Stackdriver Error Reporting allows you
to monitor your application’s errors,
aggregated into meaningful groups
tailored to your programming language and
framework. This helps you see the problems
rather than the noise.
Monitor your application errors with Stackdriver Error Reporting
https://cloud.google.com/blog/products/gcp/monitor-your-application-errors-with-stackdriver-error-reporting
Slide 70
Slide 70 text
Copyright © 2019 Studist Corporation. All Rights Reserved
新着バグ検知の利用
Slide 71
Slide 71 text
Copyright © 2019 Studist Corporation. All Rights Reserved
新着バグ検知の利用
● アプリケーションエラーを “meaningful groups” に
まとめてくれるので、新着の問題を検知できる
● 開発者自身が
Production で起きた問題に気づくために導入
● 開発した直後なら原因分析も迅速にできる
○ 時間が経つと忘れるので、
すぐに開発者にフィードバックできることが重要
Slide 72
Slide 72 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Recap
Slide 73
Slide 73 text
Copyright © 2019 Studist Corporation. All Rights Reserved
Recap
● NoOps を実践するにあたり SRE 本は最高の教材
○ 実践し、フィードバックループをまわす
○ 「DevOps 3つの道」を忠実に
- フロー改善, フィードバック, 継続的な学習と実験
● Engineering Manager としてチームとやってきたことを紹介
○ Engineering Manager のお仕事についても
懇親会で議論できればうれしみ
● 他にも、ミドルウェアやインスタンスの自動復旧も実装されている
○ 今日は、やっていることを一部紹介しましたが、全部知りたい人は…
Slide 74
Slide 74 text
Copyright © 2019 Studist Corporation. All Rights Reserved
We are hiring!
“伝えることを、もっと簡単に。”
https://studist.jp/
Slide 75
Slide 75 text
#srelounge にもきてね
Slide 76
Slide 76 text
Copyright © 2019 Studist Corporation. All Rights Reserved
#sresession もきてね
（明日だよ、ちょうどテーマが Eliminating Toil）
Slide 77
Slide 77 text
Copyright © 2019 Studist Corporation. All Rights Reserved
参考文献
I Don’t Want DevOps. I Want NoOps.
https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/
Augment DevOps With NoOps
https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203
jallspaw/gist:2140086
https://gist.github.com/jallspaw/2140086
Ops, DevOps and PaaS (NoOps) at Netflix
http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html
NoOps != No Operations
https://www.slideshare.net/dtzar/noops-no-operations?qid=0ed06484-5b59-447b-a23b-bb77afd55d95&v=&b=&from_search=40
NoOps: Its Meaning and the Debate around It
https://www.infoq.com/news/2012/03/NoOps/
Does the Future of DevOps Lie in NoOps?
https://devops.com/future-devops-lie-noops/