$30 off During Our Annual Pro Sale. View Details »

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

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

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

katsuhisa_
PRO

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

    View Slide

  2. Copyright © 2019 Studist Corporation. All Rights Reserved
    #NoOpsJP
    イベントハッシュタグ

    View Slide

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

    View Slide

  4. Copyright © 2019 Studist Corporation. All Rights Reserved
    “伝えることを、もっと簡単に。”

    https://studist.jp/

    会社紹介

    View Slide

  5. Copyright © 2019 Studist Corporation. All Rights Reserved
    サービス紹介

    View Slide

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

    View Slide

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

    View Slide

  8. Copyright © 2019 Studist Corporation. All Rights Reserved
    NoOps とは

    View Slide

  9. Copyright © 2019 Studist Corporation. All Rights Reserved
    フォレスター・リサーチ社のレポート(2011/4)
    https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203

    View Slide

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

    View Slide

  11. Copyright © 2019 Studist Corporation. All Rights Reserved
    フォレスター・リサーチ社のブログ(2011/2)
    https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/

    View Slide

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

    View Slide

  13. Copyright © 2019 Studist Corporation. All Rights Reserved
    Netflix のエンジニアのブログ(2012/3)
    http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html

    View Slide

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

    View Slide

  15. Copyright © 2019 Studist Corporation. All Rights Reserved
    Netflix のエンジニアのブログへ言及したドキュメント(2012/3)
    https://gist.github.com/jallspaw/2140086

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  20. Copyright © 2019 Studist Corporation. All Rights Reserved
    岡さんが提唱する 「No "Uncomfortable" Ops」 の内訳
    https://www.slideshare.net/hiromasaoka/15-noops

    View Slide

  21. Copyright © 2019 Studist Corporation. All Rights Reserved
    NoOps !=
    No Operations

    View Slide

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

    View Slide

  23. Copyright © 2019 Studist Corporation. All Rights Reserved
    https://landing.google.com/sre/books/

    View Slide

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

    View Slide

  25. Copyright © 2019 Studist Corporation. All Rights Reserved
    SRE と NoOps
    ● SRE では、「No "Uncomfortable" Ops」に相当する文脈として
    「Eliminating Toil」がある

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  29. Copyright © 2019 Studist Corporation. All Rights Reserved
    Eliminating Toil at
    Studist SRE Team

    View Slide

  30. Copyright © 2019 Studist Corporation. All Rights Reserved
    Toil の計測

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. 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 まみれだった
    どうやってここにたどり着いたか?

    View Slide

  36. Copyright © 2019 Studist Corporation. All Rights Reserved
    Toil Management Strategies

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  41. Copyright © 2019 Studist Corporation. All Rights Reserved
    Design Document を書く

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  48. Copyright © 2019 Studist Corporation. All Rights Reserved
    スタディストにおける SLO の活用

    View Slide

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

    View Slide

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

    View Slide

  51. Copyright © 2019 Studist Corporation. All Rights Reserved
    Provide Self-Service Methods
    ● 開発者から依頼を受けて仕事をするのではなく、
    開発者自身にやってもらえるようにする
    ● チケットドリブンでの仕事は、組織の経済的な無駄を生む

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  55. Copyright © 2019 Studist Corporation. All Rights Reserved
    Self-Service を構成する 3つの要素
    Self-Service Operations
    https://www.rundeck.com/self-service

    View Slide

  56. Copyright © 2019 Studist Corporation. All Rights Reserved
    Traditional Ops Silo
    Self-Service Operations
    https://www.rundeck.com/self-service

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  63. 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 でのテスト実行

    View Slide

  64. 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クリックでロールバック

    View Slide

  65. 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クリックでロールバック

    View Slide

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

    View Slide

  67. Copyright © 2019 Studist Corporation. All Rights Reserved
    Stackdriver カスタムメトリクスを活用したジョブキューの可視化

    View Slide

  68. Copyright © 2019 Studist Corporation. All Rights Reserved
    Stackdriver カスタムメトリクスを活用したジョブキューの可視化

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

    View Slide

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

    View Slide

  70. Copyright © 2019 Studist Corporation. All Rights Reserved
    新着バグ検知の利用

    View Slide

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

    View Slide

  72. Copyright © 2019 Studist Corporation. All Rights Reserved
    Recap

    View Slide

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

    View Slide

  74. Copyright © 2019 Studist Corporation. All Rights Reserved
    We are hiring!
    “伝えることを、もっと簡単に。”

    https://studist.jp/


    View Slide

  75. #srelounge にもきてね

    View Slide

  76. Copyright © 2019 Studist Corporation. All Rights Reserved

    #sresession もきてね

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


    View Slide

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

    View Slide