Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

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

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

NoOps Meetup #6 ( https://noops.connpass.com/event/131553/ ) でお話した内容です。スタディストのSREチームは、サービス運用やToilに関係する作業時間は、週のうち5%〜10%程度に維持しています。ここに至るまでのスタディストの実践例を、SREのプラクティスを交えてお話しました。

katsuhisa_

June 04, 2019
Tweet

More Decks by katsuhisa_

Other Decks in Technology

Transcript

  1. Copyright © 2019 Studist Corporation. All Rights Reserved NoOpsを実現するSREの存在意義と役割 class

    SRE implements NoOps 株式会社スタディスト 北野 勝久 NoOps Meetup #6 2019/06/04
  2. Copyright © 2019 Studist Corporation. All Rights Reserved 北野 勝久

    / @katsuhisa__ Katsuhisa Kitano 株式会社スタディスト 開発部 SRE Linux カーネルと同い年 Organizer of SRE Lounge Developers Summit 登壇 etc...
  3. Copyright © 2019 Studist Corporation. All Rights Reserved NoOps とは一体なんだったのか

    STEP 1 SRE と NoOps STEP 2 Eliminating Toil at Studist STEP 3 Agenda
  4. Copyright © 2019 Studist Corporation. All Rights Reserved NoOps とは一体なんだったのか

    STEP 1 SRE と NoOps STEP 2 Eliminating Toil at Studist STEP 3 Agenda
  5. 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.
  6. 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.
  7. Copyright © 2019 Studist Corporation. All Rights Reserved Netflix のエンジニアのブログ(2012/3)

    http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html
  8. 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.
  9. 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.
  10. 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".
  11. Copyright © 2019 Studist Corporation. All Rights Reserved NoOps の一連の話題について僕が思うこと

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

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

    "Uncomfortable" Ops」 の内訳 https://www.slideshare.net/hiromasaoka/15-noops
  14. Copyright © 2019 Studist Corporation. All Rights Reserved NoOps とは一体なんだったのか

    STEP 1 SRE と NoOps STEP 2 Eliminating Toil at Studist STEP 3 Agenda
  15. 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/
  16. Copyright © 2019 Studist Corporation. All Rights Reserved SRE と

    NoOps • SRE では、「No "Uncomfortable" Ops」に相当する文脈として 「Eliminating Toil」がある
  17. 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/
  18. Copyright © 2019 Studist Corporation. All Rights Reserved SRE と

    Toil SRE は Toil を業務時間の 50% 以下におさえる ⇒ どうやって Toil を撲滅する?そもそも Toil をどうやって計測する?
  19. Copyright © 2019 Studist Corporation. All Rights Reserved NoOps とは一体なんだったのか

    STEP 1 SRE と NoOps STEP 2 Eliminating Toil at Studist STEP 3 Agenda
  20. 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/
  21. Copyright © 2019 Studist Corporation. All Rights Reserved スタディストでの業務分類 1.

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

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

    at Studist SRE Team • KANNBAN に先ほどの分類ごとにレーンを設け、タスク管理 • すべての業務にポイントを付与 ◦ ポイント≒業務に要する時間の目安 • 週の終わりに、業務のポイントの割合を計測 ◦ Toil に要した時間や、OKR に集中できた時間を可視化 • (余談)戦略的に取り組むタスクは Backlog で管理し、優先度づけ ◦ Toil や Overhead は Backlog には入れず、 発生都度ポイントを付与し、KANNBAN にタスク追加 ベロシティも計測しているが、 作業時間割合の計測をより重視 ⇒ チームの時間の使い方の健全性を維持 ⇒ 今期の Toil の割合は、 5%〜10% を推移
  24. 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 まみれだった どうやってここにたどり着いたか?
  25. 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/
  26. 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
  27. 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
  28. Copyright © 2019 Studist Corporation. All Rights Reserved Engineer Toil

    Out of the System • Toil を減らすためには、そもそも Toil が生まれないようなシステムにする • 既存のシステムにおける Toil を減らすことに投資する前に、 システムを変えられないか?を考える • また、新しくつくるシステムやコンポーネントを、 Toil が生まれにくいようにする
  29. Copyright © 2019 Studist Corporation. All Rights Reserved Design Document

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

    を書く • 不可逆性の高い部分はどこか? • 性能面で詰まる可能性が高い部分はどこか? • なぜ、その設計だとダメなのか? • Design Document は必ず書く • Postmortem を書くのと同じくらい重視 • 障害を収束させた人間より、 障害を生まなかった人間を評価したい 評価フィードバックの場や、 常日頃のコミュニケーションでも デザインドキュメントの重要性を チームに繰り返し語る
  31. 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
  32. 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
  33. Copyright © 2019 Studist Corporation. All Rights Reserved Use SLOs

    to Reduce Toil • SLO? ◦ 稼働率 100% ではなく、 99.9% のようにダウンタイムを許容する ▪ != SLA • 過剰にダウンタイムを高めようとすることは、 他のタスクにかける時間を必要以上に失う ◦ 98点→99点の労力は、80点→90点の労力より大きい ◦ SLO を定義しておくことで、 必要以上の性能目標を目指し Toil が膨張しすぎることを防ぐ
  34. Copyright © 2019 Studist Corporation. All Rights Reserved スタディストにおける SLO

    の活用 • 性能面に先手を打つことで、 新たな Toil が生まれないようにする • チームの協力があってこそ運用できているので、 チームのみんなには本当に感謝
  35. 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
  36. Copyright © 2019 Studist Corporation. All Rights Reserved Provide Self-Service

    Methods • 開発者から依頼を受けて仕事をするのではなく、 開発者自身にやってもらえるようにする • チケットドリブンでの仕事は、組織の経済的な無駄を生む
  37. 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/
  38. 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
  39. 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
  40. Copyright © 2019 Studist Corporation. All Rights Reserved Self-Service を構成する

    3つの要素 Self-Service Operations https://www.rundeck.com/self-service
  41. Copyright © 2019 Studist Corporation. All Rights Reserved Traditional Ops

    Silo Self-Service Operations https://www.rundeck.com/self-service
  42. Copyright © 2019 Studist Corporation. All Rights Reserved “Rigid” Self-Service

    Self-Service Operations https://www.rundeck.com/self-service
  43. Copyright © 2019 Studist Corporation. All Rights Reserved AWS Organization

    を活用した Governance 構築 • AWS Organization を活用し、 Governance を構築する ◦ 開発者自身で必要なものを考え 自分たちで構築できるように AWS の権限を付与 ◦ 一方、単なる権限付与では、 Governance 構築は不十分
  44. 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
  45. 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
  46. 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
  47. 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 でのテスト実行
  48. 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クリックでロールバック
  49. 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クリックでロールバック
  50. Copyright © 2019 Studist Corporation. All Rights Reserved 開発者による問題検知を促進するモニタリング基盤 •

    性能的な問題検知 ◦ Stackdriver による Uptime Check でレイテンシを計測 ◦ 非同期処理に関しても、ジョブキューの滞留状況を計測 ◦ NewRelic で Apdex の監視 • 機能的な問題検知 ◦ NewRelic でエラーレートの監視 ◦ Stackdriver Error Reporting で、新着エラーをアラート • 分析基盤 ◦ fluentd でログを Elasticsearch/Kibana に集約
  51. Copyright © 2019 Studist Corporation. All Rights Reserved Stackdriver カスタムメトリクスを活用したジョブキューの可視化

    • • 実際の処理がない空ジョブを定期的にキューに入れ、 「キューに突っ込む時間」と「実際に処理された時間」の差分を Stackdriver のカスタムメトリクスとしてポストし、可視化 • キュー内のジョブ滞留時間が長くなると、アラート
  52. 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
  53. Copyright © 2019 Studist Corporation. All Rights Reserved 新着バグ検知の利用 •

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

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

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

  56. Copyright © 2019 Studist Corporation. All Rights Reserved 
 #sresession

    もきてね
 (明日だよ、ちょうどテーマが Eliminating Toil)

  57. 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/