Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

dely SRE Principles

2,770 views

Published on

SRE Rounge #1の資料

Published in: Business
  • Be the first to comment

dely SRE Principles

  1. 1. クラシル1000万DL の道のり 深尾もとのぶ
  2. 2. 自己紹介 深尾もとのぶ(0x27歳) 元料理人(ピザ職人) 最近ハマっているもの  タコライス
  3. 3. Google 翻訳アプリは、あなた の言葉をドイツ語、日本語、 チェコ、ズールー語など 90 の言語 に翻訳します ダウンロード数 1000万突破!
  4. 4. 1000万DLの道のり ・うまくいったこと ・うまくいかなかったこと
  5. 5. 2017年は どんな1年だった?
  6. 6. どんな1年だったか? ・前半は成長が早い ・後半は変化が早い
  7. 7. 成長が早い ・DAUは半年で10倍 ・テレビ番組でWebダウン(2017-03) ・予定を前倒しでTV CM(2017-04) ・ボトルネックが次々と顕在化 ・エンジニアはまだ増えず
  8. 8. うまくいったこと ・スケジュールに間に合う ・TV CM ・プッシュ、ログ収集基盤 ・チームビルディング ・スキーマ変更に強い設計
  9. 9. WHY? うまくいった理由 ・やり方にこだわらない ・スケーラビリティの確保  ・ログ収集基盤の負荷テスト ・自律的に行動できる組織 ・それぞれが長所を活かす
  10. 10. うまくいかなかったこと ・技術的負債 ・プッシュ送信サービスの障害 ・開発・運用の自動化 ・疲弊し過ぎ ・採用(なかなか増えず)
  11. 11. WHY?(うまくいかなかった) ・レビュー不足 ・成熟していない新しいサービスの利用 ・達成できる目標を定めていない ・広報活動が十分できていない
  12. 12. どうしたか? ・Tech Blog ・障害対応訓練  (dely Apollo Program) ・サービスレベル目標
  13. 13. どんな後半だったか? ・変化が早い
  14. 14. 変化が早い ・みんなのレシピ、献立 ・マネタイズ(広告、有料会員) ・新規事業の開始、撤退 ・組織編成 ・オフィス引っ越し
  15. 15. うまくいったこと ・スケジュールに間に合う ・採用 ・運用ルールの明文化  (dely SRE Principles) ・入社オンボーディング
  16. 16. 入社オンボーディング 新しくエンジニアが入る時にその人に期待 することやスムーズに業務に入るために必 要な情報を書いたもの
  17. 17. 入社オンボーディング うまく機能すれば、新しい人が自律的に行 動できるので、レバレッジが効いてここに かける時間が戻ってくる。
  18. 18. うまくいかなかったこと ・生産性が上がらない ・開発手法が定まらない (かんばん、会議体、Redmine) ・1つの作業に集中できない (社内インフラ、環境の変化)
  19. 19. うまくいっていること       の話
  20. 20. うまくいってること ・サービスレベル目標 ・運用ルールの明文化 (dely SRE Principles)
  21. 21. SRE Principles       の話
  22. 22. SRE Principlesとは ・ミッション ・最小限のルール
  23. 23. 決定の背景 ・属人化の排除 ・チームの方向 ・動機づけ ・自律的に行動
  24. 24. SRE Principles 外れてはいけないルール  ❌ 自由に行動できるエリア  ⭕
  25. 25. SRE Principlesの要素 ミッション、構成管理 サービスレベル目標 リリースエンジニアリング インシデント対応・管理、モニタリング タスク管理、セキュリティ
  26. 26. SRE Mission
  27. 27. SRE Mission ・サービスの信頼性を確保する ・意思決定に必要な指標を取得し正確であ ることを保証する ・開発部の生産性を高める
  28. 28. SLO (サービスレベル目標)
  29. 29. SLOの例 ・APIの稼働率、99.99% ・95%ile Latency 0.5sec ・ログ欠損率 1%未満/day
  30. 30. SLOの何が良いか? ・減点方式から目標達成方式に転換 ・信頼性をあげる作業には終わりがない  →どこまでやるかを決める
  31. 31. どうやって決めているか? ・ユーザ目線 ・すでに取得できている指標や習得しやす い指標を使う ・今のパフォーマンスを基準にしない
  32. 32. タスク管理
  33. 33. タスク管理  Why, Whatを決めて  When, Who, Where, How  を決めない
  34. 34. WHY を共有 ・優先順位を決めるためには  背景の理解が必要 ・送り手と受け手が目的を共有 ・タスクへのモチベーション
  35. 35. What を共有 ・何をやるのか定義 ・何をやらないかを定義(スコープ) ・やりすぎやダブりを防ぐ
  36. 36. How は決めない ・使用言語や技術は自由 ・生産性が高い手法は  本人が一番わかっている ・やり方に口を出すことは  心理的安全性を脅かす
  37. 37. Who は決めない ・誰かがアサインするのではなく、  自分からタスクを拾う ・それぞれが得意な分野を活かす  (比較優位で生産性を上げる) ・モチベーション
  38. 38. When は決めない ・「お手すき」という名の「なる早」 ・自分で優先順位を決める
  39. 39. 構成管理 (リソースマネジメント)
  40. 40. 構成管理 ・サーバやコンテナにタグをつける   product: kurashiru   role: admin, web, api   environment:    production, staging
  41. 41. 2種類の名前 ・リソースを識別する名前(EC2ID, 固有名 詞、物理名) ・役割(タグ、論理名)
  42. 42. リリースエンジニアリング
  43. 43. リリースエンジニアリング ・原則として自動化 ・開発者自身がデプロイできる ・変更管理
  44. 44. リリースエンジニアリング ・RUNDECK ・シェルスクリプト ・Slack ・Chatbot ・Redmine, Googleカレンダー
  45. 45. インシデント管理
  46. 46. インシデント管理 ・調査が必要なインシデントは 専用Slackチャンネルをオープン ・インシデントチケットから Postmortemに変更
  47. 47. 従来のインシデント管理 ・根本原因と再発防止策 ・正確な根本原因の特定は大変 ・対策を施さないとCloseできない? ・情報共有が目的  (TODO管理は別のしくみ)
  48. 48. Postmortem ・タイムライン ・よかったこと ・悪かったこと ・幸運だったこと ・対策はタスク管理で行う
  49. 49. まとめ
  50. 50. 僕が伝えたいことが2つ ・障害=悪ではなく、SLOを達成する ・自律的に行動できるチーム
  51. 51. 自律的に行動するチーム ・ビジョンを共有  ・同じ方向に向かう ・各々が自由に行動  ・生産性と心理的安全性 ・どこまでやって良いかは明文化
  52. 52. おしまい

×