以下勉強会のメモと感想です。

DIPのSREの活動とこれから(ディップ株式会社 bayashi_ok さん)

  • バイトルなどの求人情報サービスを運営
  • SREのスタート(小規模、中規模、大規模)
    • 小規模だとはじめやすい
  • DIPは会社規模は大きめ
    • 入社時110人、インフラ8人
    • 規模が拡大してきたのでSREとしての取り組みをはじめた
  • 自動化
     - Ansible
     - 導入の問題(Git, Ansible, コード化メリット)
  • 分からない背景
    • 問題を問題だと気がついていない
    • 気づいていないから学べない
    • よくわからないから変えたくない
  • コード化するメリットを教える
  • 作業の効率性を意識させる
  • 他社事例を教える->メンバーの安心感を得る
  • Git, Ansibleの使い方を何度もレクチャー、丁寧な説明
  • 変更する頻度の高いサーバーから導入
  • 結果、コード化する文化が根付いた
  • 承認フローを確立
  • 作業ミスの軽減、冪等性の担保
  • リリース作業負荷の軽減
  • ログの可視化
  • アラートには出ない404エラーが多数発生
  • 可視化で見えてきたものを元手に組織の連携
  • 速度改善が会社で依頼
  • Fastly導入
  • モバイルサイトUXレポートでカテゴリ単位の総合評価No.1

タップルSREの軌跡と描く未来(株式会社サイバーエージェント 袴田類さん)

  • タップルSREのリーダー
  • DevOpsチームの解散を経験
  • 課題解決型チームだった
  • 負債返却とシステムの更新
  • コスパのいい課題に重点をおいてやっていた(工数は低いけどインパクトがでかい)
  • 課題解決のインパクトが出しづらくなってしまった
  • ボーナスチャンスを優先的に解決
  • 工数がでかい課題が増えた
  • 足元課題の解決型チームからの脱却
  • 事業目線に立つことが重要
  • 足元課題解決を行いつつ、事業課題を解決
  • 足元課題を極力SLOとして計測可能にする
  • 組織の理想状態の実現に向けて中長期戦力を実行
  • 現状、信頼性担保に振り切れていない
  • SLO
    • アプリケーションメトリクスから作成するSLO
    • 稼働率
    • サクセスレート
    • レスポンスタイム
    • 組織も抱えるリスク
  • リスクスコア
    • 未実施の障害再発防止策をスコア化
    • 障害対応スキルレベルのSPOF
    • セキュリティー対策
    • 自動化可能作業
    • CS問い合わせ数
  • Draw.ioを使ってアーキテクチャ図を共有
    • 新しいメンバーがそれを見ればわかるようになっている
    • 障害の影響度がわかる
  • 障害対応の義務化
  • pagerdutyで障害対応
  • リスクアセスメントシートを運用してセキュリティリスクの対応を行っていた
  • 緊急度が低いが、重要性の高いリスクはマネジメントが必要
    • マネジメントしないと絶対やらない
  • SREとしての理想状態に向けてロードマップを作成(中長期戦略)
  • 事業に寄り添ったSREチーム
  • セキュアベース
  • SREで絶対的安心感を作りつつ、組織の全体のチャレンジに貢献したい

エムスリーはどのようにしてSREを始めたか(エムスリー株式会社  tshoheさん)

  • SREは組織横断
  • リーダー1, メンバー4, セキュリティーチーム兼任1
  • 従来のインフラの作業
  • Toilの削減
  • スタート時は品質改善の判断が曖昧
    • SLI/SLO監視をすることからSREチームははじまった
  • SLO計測の対象サービスを決めた(小さくはじめて徐々に増やしていく)
  • 計測対象の指標(SLI)を決めた(稼働率とレスポンスタイム)
  • SLIの計測(Nagiosでダウンタイムを計測してESで収集, NodePingで外形監視)
  • 初回SLOの決め方
    • 全社的な性能要件がきまっていたのでそれを設定した
    • 月間稼働率: 月間99.9%, 1000ms未満
  • SRE WorkBookが参考になった
  • SLOを超過していればSlack通知するようにしている
  • 月間SLOを超過したら、JIRAにもチケットを作成
  • SLOの定期的な見直し
    • 各サービスの開発陣とSREとでミーティング
    • SRE本のプラダクションミーティングとよばれるもの
  • しきい値を双方合意の上きめているので改善を促しやすい
  • SRE Workbookのバーンレートアラート

感想

最近SRE Loungeに行けていなかったので、参加した。
場所はアベマタワーで渋谷のセンター街を抜けていくのがちと辛かった。
しかし、アベマタワーはめちゃくちゃキレイで、SRE Loungeのあった部屋は相当広かったし、今回の参加者も100人以上いた様子。
今回の内容も素晴らしかった。
DIPさんの内容では、組織とコミュニケーションの機会が増えたようで、特にサイトレスポンスが重要なサービスだからこそトップダウンでサイトの速度改善が依頼があったのだなと思ったし、それに答えるべく技術課題を改善していった様子が伺えた。
タップルさんの内容は、とてもクレバーなリーダーさんだなという印象が強かった。
特にOpsをやっているとやっている内容が見えないので評価されにくいという課題があるが、必要な値をしっかりと数値化した上で、組織課題を改善していくのに全力を注ぎ、数値がラインを越えたら改善に力を注ぐというのが、かなり理想的な動きなのかなと思った。
そして自分たちがセキュアベースとなって、その上でみんなに挑戦してもらうというのが、本当素晴らしいなと思った。
エムスリーさんの内容でも、印象的だったのはSLOの話で、性能要件が明確であるというのはデカイかなと思ったのと、それをベースに各サービスと調整しているというのは大変参考になった。SRE Workbookは未読なので読んでみようと思う。

各社さんとも、組織が求めるものと自分たちのやるべきことやりたいことのバランスがうまく取れるような取り組みをされているという印象。
自分には不足している考え方なので大変参考になったし、それらの中で自分が出来ることはなんなのか改めて考えていきたい。

カテゴリー: Daily