SRE大全 スタディスト編 後半 #hbstudy 85 / SRE Taizen Studist 2

C0479b152c326746e911be790617f75b?s=47 katsuhisa_
October 31, 2018

SRE大全 スタディスト編 後半 #hbstudy 85 / SRE Taizen Studist 2

#hbstudy 85 「SRE大全 スタディスト編」で登壇した際の資料(後半)です。
前半の資料はこちら。
https://speakerdeck.com/katsuhisa91/sre-taizen-studist-1

C0479b152c326746e911be790617f75b?s=128

katsuhisa_

October 31, 2018
Tweet

Transcript

  1. SRE大全: スタディスト編 [後半] 2018/10/31 hbstudy#85 @katsuhisa__ / Katsuhisa Kitano Copyright

    (C) 2018 Studist Corporation. All Rights Reserved
  2. 自分が話せそうなこと • 0からのSRE 実践&定着の経験 ◦ 何からはじめるか、何を変えるか • SRE チームのマネージャー職として 考えていることの共有

    ◦ 採用やチームづくり 前半 後半
  3. Agenda [後半] • スキルマップ • SRE の採用と育成 ◦ SRE として大事な価値観

    • スタディストSRE チームが目指す方向性
  4. スキルマップ

  5. スタディスト SRE スキルマップ(一部) Ops DevOps Security Other 設計・構築 監視 障害対応

    データ分析 思想 ツール Hashicorp AWS Linux/Ubuntu/shell Stackdriver NewRelic Elastic Stack Terraform Packer Ansible Serverspec git, docker, Circle CI 可用性 負荷分散 SLI/SLO OnCall Postmortem Deep Security ドメイン知 識 Code Series サービス構成 Rails Inspector,CloudTrail, Guard Duty, WAF Redshift Athena BigQuery Redash CloudWatch RDBMS
  6. スタディスト SRE スキルマップ(一部) Ops DevOps Security Other 設計・構築 監視 障害対応

    データ分析 思想 ツール Hashicorp AWS Linux/Ubuntu/shell Stackdriver NewRelic Elastic Stack Terraform Packer Ansible Serverspec git, docker, Circle CI 可用性 負荷分散 SLI/SLO OnCall Postmortem Deep Security ドメイン知 識 Code Series サービス構成 Inspector,CloudTrail, Guard Duty, WAF Redshift Athena BigQuery Redash CloudWatch ここだけでもボリューム めちゃくちゃでかい Rails RDBMS
  7. スタディスト SRE スキルマップ(一部) Ops DevOps Security Other 設計・構築 監視 障害対応

    データ分析 思想 ツール Hashicorp AWS Linux/Ubuntu/shell Stackdriver NewRelic Elastic Stack Terraform Packer Ansible Serverspec git, docker, Circle CI 可用性 負荷分散 SLI/SLO OnCall Postmortem Deep Security ドメイン知 識 Code Series サービス構成 Inspector,CloudTrail, Guard Duty, WAF Redshift Athena BigQuery Redash CloudWatch 他に書いていないスキル e.g. 負荷試験, 運用自動化, Log ... Rails RDBMS
  8. スキルマップの意義: 地図 • 大まかな全体地図がないと 自分がどこにいるのかが分かりにくい ◦ 何が得意で、何が得意でないのか ◦ どこを目指したいか •

    SRE は責務を果たすためのスキルセットが 幅広く求められるので、なおさら
  9. スキルマップの役割・使い方 • Onboarding プロセスの言語化 • スタディストSRE の全体は、こんな感じ • Onboarding では、ここまでは必要ですかね

  10. スキルマップの中で何が大事か?

  11. ぜんぶ

  12. 優先順位 • 思想や設計に近い部分から頭に入れる • ツールは、(まずは、)使い方よりも存在意義 ◦ なぜ他のツールではダメなのか • 異なる存在意義のツールを適切に組み合わせて 一つの目的を達成する能力

    ◦ また、組み合わせるための糊を扱う能力
  13. スタディストSRE の優先順位 • SRE の共通言語を持てている • OnCall 要員が持つスキルの逆算 ◦ サービス構成の理解

    ▪ AWS 構成 • EC2, ELB, RDS(Aurora), S3, CloudFront, ... ▪ Rails, RDBMS ◦ ドメイン知識 • インフラコードを自由にさわることができる ◦ Ansible / Serverspec / Packer / Terraform / Docker
  14. 実際の業務は? • スキルの組合せで行うことが多いので、 一つができれば、業務にすぐ活きるわけではない ◦ また、新規 XX 導入時のDesign Review や、

    既存 XX を移行する計画策定は スキルに留まらない視点が求められる • とはいえ、一つずつ階段を登るしかないので、 スキルマップは頭の片隅に
  15. Agenda [後半] • スキルマップ • SRE の採用と育成 ◦ SRE として大事な価値観

    • スタディストSRE チームが目指す方向性
  16. SRE の採用と育成

  17. 前提: 組織のマネージャー職とは • 組織づくりができてナンボ ◦ 採用 ◦ チームづくり ◦ ToBe

    を描いて共有する ◦ ToBe 期限からの逆算 • そして、メンバーの市場価値を上げる
  18. SRE と組織づくり

  19. Netflix の事例 Netflix が今後1年で、アメリカのインターネット トラフィック全体の3分の1を専有するようになると 突然気づいた時の話 → それまで自前のシステムを構築していたが、 AWS と契約し、AWS

    を扱うチームを採用した
  20. SRE に限らずだが、 事業成長の逆算で組織をつくる

  21. チームに、必要となる技術を 先行して伝えることも必要

  22. SRE の採用

  23. SRE's Job Description

  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. 必須要件とされているスキル • コンピュータ・サイエンス系の学位 ≒コンピュータに対する深い理解 • アルゴリズムとデータ構造 • プログラミング経験

  31. 必要最低限の記述に留め、 残りは面接で判断? ( ポジションの責務を記述するのに 各社ページのボリュームを割いている様子 )

  32. では、何を評価すべきか

  33. 「Hiring SREs」 by Andrew Fong, Dropbox https://www.youtube.com/watch?v=ucCSRY-KOCI

  34. SRE に必要な能力 • Software Skills • Systems & Networks ◦

    General “Linux” Skills ◦ Low Level Systems Knowledge ◦ Do you know how staff is put together • Architecture ◦ Tradeoffs • Troubleshooting ◦ Logical Thinking ◦ Depth of knowledge • Soft skills ◦ Customer Service ◦ Priorization
  35. SRE に必要な能力 • Software Skills • Systems & Networks ◦

    General “Linux” Skills ◦ Low Level Systems Knowledge ◦ Do you know how staff is put together • Architecture ◦ Tradeoffs • Troubleshooting ◦ Logical Thinking ◦ Depth of knowledge • Soft skills ◦ Customer Service ◦ Priorization 個人的には、納得感ある分類
  36. どうやって面接で評価するか 面接の全体像(Funnel)は、ここでは触れない

  37. Onsite Interview • 業務内容から業務を深掘りし、状況質問する ◦ ◯◯の時、なぜその判断をしたか ▪ 選択肢としては、A やB もあったのでは?

    • システムの振る舞いをホワイトボードに 記述してもらう ◦ 個別の技術要素も質問する • 自社カルチャーとの相性もこの時に見る
  38. Onsite Interview • 業務内容から業務を深掘りし、状況質問する ◦ ◯◯の時、なぜその判断をしたか ▪ 選択肢としては、A やB もあったのでは?

    • システムの振る舞いをホワイトボードに 記述してもらう ◦ 個別の技術要素も質問する • 自社カルチャーとの相性もこの時に見る 構造化面接など、面接精度を上げる 取り組みはこれから整備
  39. オススメ  Interviewing  Site Reliability Engineers  by Andrew Fong, Dropbox

  40. SRE の育成

  41. Onboarding

  42. Onboarding: 1 month • ランチ設定 • キャリアポートフォリオ策定 • SRE にとって大事なマインド共有

    • 輪読: SRE 本、インフラエンジニアの教科書2 • サービス研修: Teachme Biz のプロダクト価値を知る
  43. Onboarding: 1 month • 開発ツール研修: Teachme Biz を動かす • プロダクト研修:

    Teachme Biz システムのドメイン知識 • CRE 研修: 顧客要望や問い合わせ内容の例を知る • AWS 研修 • Teachme Biz 構築研修: AWS に同じ構成を再現する • Onboarding 報告会 • Onboarding おつかれさま会: 振り返りと今後の意識共有
  44. None
  45. 自分は何が得意か、何をやりたいか 何をやっている時に意味を感じるか →未来につなげる

  46. SRE にとって大事な マインド共有 約1,800 文字のドキュメント 後ほど一部紹介

  47. 輪読の前に やる意義を共有 事前提示したテーマに関し、 書籍から学んだ内容を、 最終日に発表

  48. None
  49. サービス研修 • 営業チームがお客様に Teachme Biz を説明する場に同席してもらう • SREも、製品や機能の価値を深く知ることは重要 ◦ 機能の顧客影響を想像しやすくなる

    ◦ トラフィック量からは分からない情報を ドメイン知識としてInput しておく
  50. これから

  51. 大事だと思っていること • 本人の意志 × チームとして目指すべき方向性 をすり合わせていく • 1on1 でフィードバックサイクルを細かく回す •

    輪読など、チームで目線をそろえる必要がある 技術トピックの学習も並行して行う
  52. その他: やっていること • AWS オンデマンドセミナーを見る会 ◦ 隔週でランチ食べながら見る • 週次ミーティングで、新しい技術トピックや、 勉強会参加した情報の共有

    • 雑談で気になる技術トピックを先出し
  53. SRE の評価

  54. 採用・育成とくれば評価だが… • 大事な価値観があり、 それに沿った行動が評価されるべきという考え • もちろん、スキルによる評価も必要

  55. SRE として大事な価値観

  56. 信頼されるために • 技術者倫理を高く持つ • 公明正大であること ◦ 公明正大でないと、障害原因調査が難しい • 人を責めない ◦

    公明正大の維持に必要 • 腕を磨く: 気合ではサービスの信頼性は守れない
  57. スケールするか • 常にスケールすることを意識する必要はないが、 SRE は、スケールの観点は常に持つべき • ソフトウェアと思想は、スケールする ◦ ウェブオペレーションは、 技芸であり科学ではない

    by 『ウェブオペレーション』
  58. チームで成果を出す • SRE の業務範囲は多岐にわたるので、 細分化して専任を置いたほうが 短期の開発速度は向上する ◦ しかし、特定人員が欠けると 一気に開発速度が落ちる ◦

    また、変化に弱い • チームで成果を出すことを重視
  59. Agenda [後半] • スキルマップ • SRE の採用と育成 ◦ SRE として大事な価値観

    • スタディストSRE チームが目指す方向性
  60. スタディストSRE が 目指す方向性

  61. 短期(今期) • 10+ Deploys Per Day へ ◦ デプロイにまつわる意思決定のツール化 ▪

    安全なDB migration をツールで担保する ◦ インフラ/ミドルウェア変更修正の 反映リードタイムの高速化
  62. 短期(今期) • More Monitoring ◦ 監視の網目の細かさが足りていない箇所の補強 ▪ バックグラウンドジョブ ◦ より正しい監視をつくる

    ▪ [前半] で、お話したSLI計測システムなど
  63. 中長期で見据えるコンセプト ▶ Self-Service Is More Than A Button

  64. 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
  65. Self-Service Is More Than A Button • OaaS ( Operation

    as a Service ) ◦ 必要なオペレーションは、 Self-Service で扱えるように • SRE チームがどうなるかはまだ見えていない ◦ OaaS のPlatform をつくるチームと、 OaaS 周辺の問題解決に専門性を持つチーム に大きく分かれる?
  66. スタディストSRE は、 まだ はじまったばかり・・・

  67. Copyright (C) 2018 Studist Corporation. All Rights Reserved 67 #devsumiE

    自己紹介 We are hiring!! スタディストでは、 いっしょに闘ってくれるSRE を募集中