SRE Lounge #9

• 日時: 2019.05.29
• URL: https://sre-lounge.connpass.com/event/129214/
• 特徴:
  • 複数社のSREプラクティスが知れる
  • 双方向コミュニケーション。質疑応答を行う

DIPのSRE活動とこれから

• Speaker: bayashi_okさん@dip

  • システム開発部、SREチームリーダー

• SREまでの道のり

  • 2つのスタートがある
    • 少人数サービス。比較的楽...DevからOpsの流れ
    • 長年インフラをやってきたチームが自動化、クラウド化を行う。難しい...OpsからDevの流れ
    • DIPは後者
  • もともと外成果されていたサービスを徐々に内製化
  • 動機:サービスが拡大しており、このままだと成長が鈍化するため
• まずAnsibleでインフラを自動化
  • 問題:
    • ツール(git, ansible)の使い方がわからない
    • コード化するメリットがわからない
    • 問題に気づいていない。気づいていないから学べない。よくわからないから変えたくない
  • 解決策:
    • コード化するメリットを伝える
    • 作業効率を意識させる
    • 他社事例の紹介でメンバの安心感を伝える
    • ツールの伝え方を何度もレクチャー。1回だけだとわかってくれない。なじみのある言葉で説明
    • 効果が高いところから導入
    • 承認フローの確立(課長がマージ)
• 次にログ可視化
  • 問題:
    • アラートには出ない不具合が多い。原因は以下3個
    • 隣の部署のしごとがわからない
    • 問題の重要性に気づいていない
    • 対応する意味がわからない
  • 解決策:
    • 互いにメリットがあることを説明
• 次に速度改善の命令が上から来た。Googleが遅いほど直帰率が下がるよう仕様を変えたため
  • 内容はこちら
  • 画像最適化(Fastly利用)
  • 初期速度が70%改善。応募率が14%上昇
  • 転送量24%削減(画像最適化のため)
  • モバイルサイトUXレポートで想像評価No1、サイト速度No2に
• まとめ
  • コミュニケーション大事
  • 最高の設計と実装はお互いの尊重する雰囲気の基で関心が一つになったときに生まれる
• 1. ツールの導入は草の根活動と強権のどっちで進めた
  2. 1. 草の根。もともと自動化したいと皆が思っていた
• 1. 時系列分析はしている？速度とか
  2. 1. 現在は短期ログのみ可視化している。今後はBigQueryを考えている
• 1. セキュリティは
  2. 1. これから

タップルSREの軌跡と描く未来

• Speaker: 袴田類さん@マッチングエージェント
  • 日本2位のマッチングアプリサービサー
  • 開発エンジニア → DevOpsチーム → SREリーダーと変遷
• DevOpsチームが解散したときの反省
  • 業務の特徴:
    • 課題解決型で進めた。
    • 負債返却がメイン。工数が小さくてインパクトが大きいものを優先して実施。ペイオフマトリクス
    • DC移設、ミドルverupなどを行った
  • 解散理由: 課題解決のインパクトが出しにくくなった。コスパの良い課題がない。開発エンジニアを増やしたいというマネージャ要望
  • 反省: 足元課題解決型の脱却が必要。3年後の理想状態を定義し、中長期戦略を考えると良い
• 反省に基づく変更
  • 足元課題をSLOに定義
  • 事業成長に貢献できるシステムの理想状態を定義
    • SREチームだけだと難しい。エンジニアリーダーや経営層、経営ボードと協力
  • このため、信頼性担保には振り切れていない
• SLO: 2個用意
  • アプリケーションメトリクスからのSLO: 稼働率、レスポンスタイムなど
  • リスクスコア: 開発組織のリスクをスコア化し、目標値を定める。障害のSPOFなど
    • ポストモーテムのうち未実施の再発防止策をスコア化
    • 障害対応スキルレベルのSPOF。自己申告。Experience mapのほうが運用しやすい？
    • セキュリティ対策
    • 自動化可能作業: Toil
    • など
• オンボーディング
  • アーキテクチャ図を常に作っている。新メンバーがアーキを俯瞰できる
  • draw.ioで管理
• 障害対応
  • フローの整備
  • 義務化のマインドセット: 義務にするのは規則的に困難。労務に相談
  • 障害対応当番制の導入
• セキュリティ対策
  • 緊急度が低いが重要性の高いリスクは管理しないとやらない
  • リスクアセスメントで可視化し、時間があるときにつぶしていく
• ロードマップ: SLP、マイクロサービス、不具合発生の最小化、不具合の影響削減
• 事業成長に寄り添っていきたい
• SREのマインドセット: セキュアベース(ロッククライマーの命綱を握っていてくれる人)になる
  • 安心感を作り、組織にチャレンジをさせる
• QA
  • 1. リスクスコアの決め方は?
    2. 1. 障害の大きさ(問い合わせ件数)で決めている。しきい値でスコアを分類している
  • 1. 足元課題と中長期課題の割合は?
    2. 1. 足元課題をできる限りSLOにまとめ、それを達成できている間は中長期課題を実施
  • 1. リスクスコアの管理方法は?
    2. 1. gitlabのIssueで管理し、datadogで可視化(gitlabのラベルを紐づけている)
  • 1. 障害対応を皆ができるようになるための工夫は？
    2. 1. ローテーションにすることで責任感を持たせる

エムスリーはどのようにしてSREを始めたか

• Speaker: tshoheさん@M3
  • M3のSRE第一号
  • ansible, terraform, ログ監視など
  • M3は医師向けのニュースサイト、質疑応答サイト。65人
• SRE
  • 昨年の11月にできた
  • 6人。リーダー1人、メンバー4人、xx1人
• 初期状態
  • アプリの品質改善の判断が曖昧。エンジニアが主観で実施。
  • SLOを決めるところから始めた
  • 小さく初めて範囲を広げるアプリーチが良い。
  • 主要サービスからスタート
• SLI
  • 稼働率: ヘルスチェック。200がかえるかどうか
  • レスポンスタイム: サーバサイドのレスポンスタイムのみ
  • 最初はあまり頑張らない
• 計測
  • DC内のNagios, NodePing(外からURLを叩くサービス)を使っている
  • Elasticsearchに保存。すでに一部データが入っていたため。
  • 最近はDataDogの利用も増やしている。terraformで管理できるため便利
  • RTはFluentdで収集。長期保存するためサンプリングしている。
• SLOの決め方
  • 性能要件が決まっていれば採用。月間稼働率99.9%
  • RTは98-99%ileが1s未満
  • The Site Reliability Workbookを参考にクラス分けしようとしている
  • 月1のページで見直し。本来は毎週だが人がユニットに分かれているためコストが大きい
• 可視化
  • Kibanaを仕様
  • SLO一覧ページからリンク
  • オンプレ環境はGrafanaも使っている
• アラート設定
  • Elasticsearchからpacentile aggretationをバッチで計算
  • アラートの値が難しい
  • SLOを超過したらJIRAにチケット + Slack通知
  • 担当者は優先度を上げて改善。短期解決が困難な場合は条件緩和などの救済措置
• まとめ: SLOの監視ができるようになった
• 今後:
  • SLOの変更ルールを厳密にしたい。
  • DecisionMatrixを使いたいが難しい。顧客満足度の測定や利益へのSLIの寄与率の判断など
  • アラートがノイジーにならないようにする。バーンレートアラートが良さそう。Error Budgetの消費速度からアラートを上げるか判断
• 告知
  • SRE Session2を開催
  • 対話型