NoOpsを実現するSREの存在意義と役割

Copyright © 2019 Studist Corporation. All Rights Reserved
NoOpsを実現するSREの存在意義と役割
class SRE implements NoOps
株式会社スタディスト　北野勝久
NoOps Meetup #6 2019/06/04

View Slide

#NoOpsJP
イベントハッシュタグ

View Slide

北野勝久 / @katsuhisa__
Katsuhisa Kitano
株式会社スタディスト開発部 SRE
Linux カーネルと同い年
Organizer of SRE Lounge
Developers Summit 登壇 etc...

View Slide

“伝えることを、もっと簡単に。” 
https://studist.jp/ 
会社紹介

View Slide

サービス紹介

View Slide

NoOps とは一体なんだったのか
STEP 1
SRE と NoOps
STEP 2
Eliminating Toil at Studist
STEP 3
Agenda

View Slide

NoOps とは

View Slide

フォレスター・リサーチ社のレポート（2011/4）
https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203

View Slide

フォレスター・リサーチ社のレポート（2011/4）
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.

View Slide

フォレスター・リサーチ社のブログ（2011/2）
https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/

View Slide

フォレスター・リサーチ社のブログ（2011/2）
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.

View Slide

Netflix のエンジニアのブログ（2012/3）
http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html

View Slide

Netflix のエンジニアのブログ（2012/3）
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.

View Slide

Netflix のエンジニアのブログへ言及したドキュメント（2012/3）
https://gist.github.com/jallspaw/2140086

View Slide

Netflix のエンジニアのブログへ言及したドキュメント（2012/3）
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.

View Slide

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".

View Slide

NoOps の一連の話題について僕が思うこと
● NoOps の “Ops” を職種や役割と捉え、理解しようとすると拒否反応が出る
○ Ops を一連の業務群だと捉えると、
一部をソフトウェアで行うことはごく自然なこと
● どこまでを Ops と捉えるかの解釈がズレると
議論がちゃんとできない
○ 「その業務を Ops のお仕事だとすると No にできなくね？」
⇒認知の離散化が起きないように議論しよう

View Slide

NoOps の一連の話題について僕が思うこと
● NoOps の “Ops” を職種や役割と捉え、理解しようとすると拒否反応が出る
○ Ops を一連の業務群だと捉えると、
一部をソフトウェアで行うことはごく自然なこと
● どこまでを Ops と捉えるかの解釈がズレると
議論がちゃんとできない
○ 「その業務を Ops のお仕事だとすると No にできなくね？」
⇒認知の離散化が起きないように議論しよう
NoOps Japan 発起人の岡さんが
「No "Uncomfortable" Ops」と提唱しているのも
このへんの背景があるはず

View Slide

岡さんが提唱する「No "Uncomfortable" Ops」の内訳
https://www.slideshare.net/hiromasaoka/15-noops

View Slide

NoOps !=
No Operations

View Slide

STEP 1
SRE と NoOps
STEP 2
STEP 3
Agenda

View Slide

https://landing.google.com/sre/books/

View Slide

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/

View Slide

SRE と NoOps
● SRE では、「No "Uncomfortable" Ops」に相当する文脈として
「Eliminating Toil」がある

View Slide

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/

View Slide

SRE と Toil
SRE は Toil を業務時間の 50% 以下におさえる
⇒ どうやって Toil を撲滅する？そもそも Toil をどうやって計測する？

View Slide

STEP 1
SRE と NoOps
STEP 2
STEP 3
Agenda

View Slide

Eliminating Toil at
Studist SRE Team

View Slide

Toil の計測

View Slide

SRE の業務を分類する（ SRE Book の教え）
1. Software engineering
- 設計、ドキュメンテーションに加えコードの作成や変更
2. Systems engineering
- 本番システムの構成の変更（OSパラメータの調整、ロードバランサ設定等）
3. Toil
- 反復的、手動などのサービスの実行に直接関係する作業
4. Overhead
- 採用業務、チーム/会社の会議、トレーニングなど
https://landing.google.com/sre/sre-book/chapters/eliminating-toil/

View Slide

スタディストでの業務分類
1. OKR Work
- OKR 達成に関連するタスク
2. Project Work
- Issue ベースで取り組まなければならないタスク
3. Toil
- 反復的、手動などのサービスの実行に直接関係する作業
4. Overhead
- 採用業務、チーム/会社の会議、トレーニングなど

View Slide

Team Monitoring at Studist SRE Team
● KANNBAN に先ほどの分類ごとにレーンを設け、タスク管理
● すべての業務にポイントを付与
○ ポイント≒業務に要する時間の目安
● 週の終わりに、業務のポイントの割合を計測
○ Toil に要した時間や、OKR に集中できた時間を可視化
● （余談）戦略的に取り組むタスクは Backlog で管理し、優先度づけ
○ Toil や Overhead は Backlog には入れず、
発生都度ポイントを付与し、KANNBAN にタスク追加

View Slide

ベロシティも計測しているが、
作業時間割合の計測をより重視
⇒ チームの時間の使い方の健全性を維持
⇒ 今期の Toil の割合は、 5%〜10% を推移

View Slide

ベロシティも計測しているが、
作業時間割合の計測をより重視
⇒ チームの時間の使い方の健全性を維持
⇒ 今期の Toil の割合は、 5%〜10% を推移
昔は、 Toil まみれだった
どうやってここにたどり着いたか？

View Slide

Toil Management Strategies

View Slide

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/

View Slide

Engineer Toil Out of the System
Use SLOs to Reduce Toil
Eliminating Toil at Studist SRE Team
Provide Self-Service Methods
1
2
3

View Slide

● Toil を減らすためには、そもそも Toil が生まれないようなシステムにする
● 既存のシステムにおける Toil を減らすことに投資する前に、
システムを変えられないか？を考える
● また、新しくつくるシステムやコンポーネントを、
Toil が生まれにくいようにする

View Slide

Design Document を書く

View Slide

● 不可逆性の高い部分はどこか？
● 性能面で詰まる可能性が高い部分はどこか？
● なぜ、その設計だとダメなのか？
● Design Document は必ず書く
● Postmortem を書くのと同じくらい重視
● 障害を収束させた人間より、
障害を生まなかった人間を評価したい

View Slide

● 不可逆性の高い部分はどこか？
● 性能面で詰まる可能性が高い部分はどこか？
● なぜ、その設計だとダメなのか？
● Design Document は必ず書く
● Postmortem を書くのと同じくらい重視
● 障害を収束させた人間より、
障害を生まなかった人間を評価したい
評価フィードバックの場や、
常日頃のコミュニケーションでも
デザインドキュメントの重要性を
チームに繰り返し語る

View Slide

より信頼性の高いコンポーネントに置き換える
https://speakerdeck.com/katsuhisa91/db-an-hao-hua-woyaretoyan-waretakedo-aurora-yi-xing-wotong-shi-nishi-xian-sitahua

View Slide

より信頼性の高いコンポーネントに置き換える
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

View Slide

1
2
3

View Slide

● SLO？
○ 稼働率 100% ではなく、 99.9% のようにダウンタイムを許容する
■ != SLA
● 過剰にダウンタイムを高めようとすることは、
他のタスクにかける時間を必要以上に失う
○ 98点→99点の労力は、80点→90点の労力より大きい
○ SLO を定義しておくことで、
必要以上の性能目標を目指し Toil が膨張しすぎることを防ぐ

View Slide

スタディストにおける SLO の活用

View Slide

スタディストにおける SLO の活用
● 性能面に先手を打つことで、
新たな Toil が生まれないようにする
● チームの協力があってこそ運用できているので、
チームのみんなには本当に感謝

View Slide

1
2
3

View Slide

● 開発者から依頼を受けて仕事をするのではなく、
開発者自身にやってもらえるようにする
● チケットドリブンでの仕事は、組織の経済的な無駄を生む

View Slide

Ticket-Driven Request Queues Are Expensive
The Principles of Product Development Flow
https://www.amazon.co.jp/dp/B007TKU0O0/

View Slide

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

View Slide

“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

View Slide

Self-Service を構成する 3つの要素
Self-Service Operations
https://www.rundeck.com/self-service

View Slide

Traditional Ops Silo

View Slide

“Rigid” Self-Service

View Slide

Self-Service

View Slide

AWS Organization を活用した Governance 構築
● AWS Organization を活用し、 Governance を構築する
○ 開発者自身で必要なものを考え
自分たちで構築できるように AWS の権限を付与
○ 一方、単なる権限付与では、 Governance 構築は不十分

View Slide

スタディストにおける AWS アカウント分割の考え方
●
AWS Organization
Admin OU Service OU
Sandbox OU
Admin
Audit
Prod Prod-Backup Stg
Sandbox
全監査ログ
保管
　アカウント
　管理
Production Backup を
保管
Staging
Sandbox
※ OU = Organizational Unit

View Slide

スタディストにおける 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

View Slide

デプロイの責務を開発者に移管
AWS CodePipeline がトリガーされる
STEP 2
AWS CodeBuild でアセットプリコンパイル
STEP 3
Production 同等環境にデプロイされ、最終動作確認ができる
※社内からのみアクセス可
STEP 4
問題なければ、承認ボタンを押し、 Production にデプロイ
STEP 5
GitHub で対象 Pull Request を master にマージ
STEP 1

View Slide

STEP 2
STEP 3
STEP 4
STEP 5
STEP 1
● 2人以上の Approve 必須
● 前提として CircleCI でのテスト実行

View Slide

STEP 2
STEP 3
STEP 4
STEP 5
STEP 1
デプロイ後に Production で
問題が起きれば、
1クリックでロールバック

View Slide

開発者による問題検知を促進するモニタリング基盤
● 性能的な問題検知
○ Stackdriver による Uptime Check でレイテンシを計測
○ 非同期処理に関しても、ジョブキューの滞留状況を計測
○ NewRelic で Apdex の監視
● 機能的な問題検知
○ NewRelic でエラーレートの監視
○ Stackdriver Error Reporting で、新着エラーをアラート
● 分析基盤
○ fluentd でログを Elasticsearch/Kibana に集約

View Slide

Stackdriver カスタムメトリクスを活用したジョブキューの可視化
●

View Slide

Stackdriver カスタムメトリクスを活用したジョブキューの可視化
●
● 実際の処理がない空ジョブを定期的にキューに入れ、
「キューに突っ込む時間」と「実際に処理された時間」の差分を
Stackdriver のカスタムメトリクスとしてポストし、可視化
● キュー内のジョブ滞留時間が長くなると、アラート

View Slide

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

View Slide

新着バグ検知の利用

View Slide

新着バグ検知の利用
● アプリケーションエラーを “meaningful groups” に
まとめてくれるので、新着の問題を検知できる
● 開発者自身が
Production で起きた問題に気づくために導入
● 開発した直後なら原因分析も迅速にできる
○ 時間が経つと忘れるので、
すぐに開発者にフィードバックできることが重要

View Slide

Recap

View Slide

Recap
● NoOps を実践するにあたり SRE 本は最高の教材
○ 実践し、フィードバックループをまわす
○ 「DevOps 3つの道」を忠実に
- フロー改善, フィードバック, 継続的な学習と実験
● Engineering Manager としてチームとやってきたことを紹介
○ Engineering Manager のお仕事についても
懇親会で議論できればうれしみ
● 他にも、ミドルウェアやインスタンスの自動復旧も実装されている
○ 今日は、やっていることを一部紹介しましたが、全部知りたい人は…

View Slide

We are hiring!
“伝えることを、もっと簡単に。” 
https://studist.jp/ 

View Slide

#srelounge にもきてね

View Slide

 
#sresession もきてね 
（明日だよ、ちょうどテーマが Eliminating Toil） 

View Slide

参考文献
I Don’t Want DevOps. I Want NoOps.
Augment DevOps With NoOps
jallspaw/gist:2140086
Ops, DevOps and PaaS (NoOps) at Netflix
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/

View Slide

NoOpsを実現するSREの存在意義と役割

NoOpsを実現するSREの存在意義と役割

katsuhisa_
PRO

More Decks by katsuhisa_

Other Decks in Technology

Featured

Transcript

NoOpsを実現するSREの存在意義と役割

NoOpsを実現するSREの存在意義と役割

katsuhisa_ PRO

More Decks by katsuhisa_

Other Decks in Technology

Featured

Transcript

katsuhisa_
PRO