2019-05-29 SRE Lounge #9 #srelounge
2019/05/29 に開催された SRE Lounge #9 のイベントレポートです。
●イベント概要
SRE Lounge とは
SRE Lounge は、 UZABASE のSRE チームが中心となり、発足した勉強会 です。
もともとは、クローズドで少人数な勉強会運営をしておりましたが、より幅広く参加者を集い、SRE 同士で交流したいという想いから、2018/6 より、オープンに参加者を募集しています。 SRE や、SRE にご興味をお持ちの方は、ぜひご参加ください。
■DIPのSREの活動とこれから
bayashi_ok さん [ディップ株式会社]
●DIP
・1997年設立
・バイトルなど
・AR, VRなどに力を入れている
●SREをはじめるアプローチ
・少人数サービス
インフラのいないサービス
Dev -> Ops
・大規模サービス
長年インフラチームから内製化
Ops -> Dev
※DIPはこちらから
●開発体制
・人数 110名(社員 40名)
・内製化を進めていた
・が、レガシー化していっていた
-> 成長速度が下がってしまう
●IaC: ansible
・導入は楽にできた
・ワカラナイ
Git, ansible, コード化のメリット
問題だと気づいていない
気づいていないから、学べない
よくわからないから、変えたくない
●メンバーの行動を変えていく
・コード化のメリット
・作業の効率を意識
・他社事例で安心感
●使い方がわかるまで教える
・git, ansibleの使い方を何度もレクチャー
同じ質問がきても粘り強く
・馴染みのある言葉で説明
●コード化する文化が根づいた
・git, ansibleの使い方を覚えた！
・承認フローの確率
・冪等性を担保する書き方が人によってまちまち
SREが入ってからマージ
●ログの可視化
・導入は比較的楽にできた
・見えてきたこと
縦割り組織の弊害
・access logを見ていると
ログに出ない不具合
404が異様に多い
いづれ大事故につながりそう
ワカラナイ
隣の部署の仕事が、ワカラナイ
エラーの危機感が、ワカラナイ
対応するメリットが、ワカラナイ
問題だと気づいていない
気づいていないから、学べない
よくわからないから、変えたくない
●隣の部署だから分からない、知らない
-> 組織間のコミュニケーションの場が広がった
・他組織のチャットに参加
・エラーコンテンツを木にするように
・チェックが拠点に広がった
自動化で、所属チームのやり方を変えた
可視化で、組織の連携を深めた
-> SREへ
●速度改善が降ってきたw
・速度面でも最高の体験を
-> DIP速度改善チーム発足
・画像最適化
CDN: FastlyのImageOptimiserを利用
画像最適化用にドメインを追加
・Fastlyのその他の恩恵
ユーザの位置情報から近いサーバに接続
HTTP2化
フルHTTPS化
サポートが手厚い！
・モバイルサイトUXレポート 2018 @Google
求人サイトカテゴリで1位
●SREの現在と今後のミッション
まだまだtoilはたくさん
様々な部署を兼任 -> 権限委譲
お互いを尊重する雰囲気のもとで
関心が1つになったときに
最高の設計と実装が生まれる
●Q: もともとFastlyを使っていた？
yes
●Q: 速度改善チームのメンバーはどんな人があつめられた？
多岐にわたる人たち
作業時間の割合は、30〜40%程度
●Q: ツール導入はどう進めた？
皆さん、自動化したい気持ちはあったので
草の根活動で広げた
●Q: サイトのスピードは応募数upにつながった？
yes
●Q: ログから過去との比較をしたりしている？
短期ログはES/kibana
長期的なログはBigQuery
■タップルSREの軌跡と描く未来
袴田類 さん [株式会社サイバーエージェント]
●DevOpsチームの解散を経験
・活動内容
課題解決型チームだった
半年ごとに活動テーマを設定
負債返却
システム刷新
・ペイオフマトリックスで優先度を設定
・やったこと
データセンター移設
ミドルウェアverupなど
・解散理由
ボーナスチャンスがなくなってきた
課題解決のインパクトが出しづらい
-> リソース投資し辛い。開発に投資したい
・反省点
足元課題解決から脱却
理想から中長期の目標を立てたほうが良いのではないか
未来を見せつつ、自分たちへの期待もつくる
事業成長への貢献
●タップルSRE
・足元課題解決
足元課題をSLOで計測可能に
・中長期戦略
事業成長に貢献する理想状態を定義
各分野のリードと連携して策定
・信頼性担保には振り切れていない
●これまでの活動
・2種類のSLO
アプリケーションメトリクス
開発組織の抱えるリスク：リスクスコア
未実施の再発防止策
障害対応スキルレベルのSPOF
・未実施の再発防止策
ポストモーテムから抽出
High/Middle/Lowで分類
・障害対応スキルレベルのSPOF
スキルマップを作成
知識カテゴリごとに合計値から判断
・オンボーディング
アーキテクチャ図の最新をキープ
Draw.io
joinしたメンバーが俯瞰できる
・障害対応
対応フロー整備
連絡網、メンテ基準、アラートごとのplaybook
義務化のマインドセット
義務として労務と相談
・セキュリティー対策
緊急度が低いが、重要性が高いものは絶対実施されない
アセスメントで優先度を整理、空いた時間にこなす
・理想状態定義、ロードマップ作成
SLO
MicroService
不具合を発生させない
アーキテクチャの標準化 etc
●セキュアベースになりたい
登山でのクライマーに対するビレイヤー
安全にリスクをとるための絶対的な安心感
-> より大きなチャレンジを促せるように
●タップル誕生
・マッチングアプリ利用率
20代の 5人に1人が利用
出会い系からイメージは変わってきた
・マーケットシェア
No.2 -> No.1へ
そのために
バックエンドエンジニアが特に不足している
●Q: 数値化するときのフローはどうしている？
リスクスコア
過去の障害での、問い合わせ件数で分類
しきい値はリーダーが集まって決定
●Q: 足元課題と中長期戦略のバランスは？
足元課題をSLOにまとめてしまう
満たしている間は中長期戦略に注力
●Q: リスクスコアの管理には何を使っている？
DataDogで可視化
GitHub Issueのラベルで設定 -> Lambda -> DataDog
●Q: 障害対応できる人を増やすためにやっていることは？
一緒に進めることで、敷居を下げている
■エムスリーはどのようにしてSREを始めたか
tshohe さん [エムスリー株式会社]
●エムスリー
テクノロジーで医療業界にイノベーションを起こすことを目指している
●SREチーム
・インフラチーム配下として新設
・ロールだけ -> 組織へ
リーダー 1名
メンバー 4名
セキュリティ兼任 1名
・新設時の状態
アプリの品質改善の判断が曖昧
-> SLO決めよう！
・対象サービスを決める
バックエンドのAPIを含めると多数
小さく始めて範囲を広げていく
影響の広い主要なサービスから
●SLI
稼働率
レスポンスタイム
・計測
外形監視は、Nagios, NodePing
ダウンタイムをAPIからElasticSearchに保存
・稼働率
Datadogに倒していっている
・レスポンスタイム
fluentd -> Elasticsearch
●SLO
初回設定が難しい
すでに合ったのでそれを採用
・Site Reliability Workbook
個別に見るのは大変
クラス分けすると良さそう
●可視化
SLI/SLOの一覧
オンプレは、kibana
AWSは、grafana
●アラート設定
windowサイズの設定が難しい
slackに飛ばしている
月間SLOを超過したらチケット登録
-> SLOを下回る、見直し などで解消
●SLOの定期的な見直し
プロダクションミーティングに近い
各サービスの開発と一緒に
3ヶ月に1回くらい
●今後
・Decision Matrixがあったほうが良さそう
顧客満足度ってどう計測する？
・バーンレートアラートが合ったほうが良さそう
ErrorBudgetの消費速度
3日くらい持つならチケット管理で
katsuhisa__ さん
各社の取り組みをプレゼン形式で発表するのとは対照に、全員参加型で密度のある議論をする場として、SRE Sessionもやっています。
■感想
・問題に気づいていない問題
・効果とコストからの優先順位づけ
・しきい値を設けて活動の切り分け
・データドリブンでの観点の難しさ
経験上、事業会社さんのDevから入ってDevOpsな活動をお手伝いをすることが多いのですが、共感できるお話をたくさん頂けました！
顧客に提供する価値を、より早く、より大きくしていくために何をするべきか、と向き合うことの大切さを改めて感じました。
登壇者の皆さん、運営の皆さん ありがとうございました！
いつも応援していただいている皆さん支えられています。