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/