先週 SRE Tech Talks #2 に参加してきた．僕も仕事ではウェブオペレーションをメインで担当しているけど，他社の事例を聞くのは刺激になるし，まだまだできてないことが多くあるなと感じた．特に「オペレーションの効率化をソフトウェアエンジニアリングで実現する」という価値観が凄い良い表現で刺さった．

On-call Engineering @cubicdaiya

SRE のミッション
- Operation（サービスの信頼性を向上させる）
- Software Engineering（サービスをスケールさせるためのツールなどを開発する）
On-call
- SRE でローテーションしている
- 1週間毎に交代する
- SRE 全員が電車通勤中であることを避けるために On-call 担当は自宅待機して時差出勤する
- On-call 当番の負担は大きい
  - 精神的なプレッシャー
  - 同居人への負担
  - 深夜問わず
- 振休や手当を支給している
- Slack Bot を活用して PagerDuty 経由で電話をかけられるようにしている
- Slack がダウンしている場合も考慮して Wiki にも電話番号をまとめている

質疑応答が大量に出てて，1番盛り上がっていた．「オンコール」という誰しも興味のあるテーマだったのも良かったんだと思う．

「オンコール」の運用としては，非常に徹底した運用をしているなと感じた．特に意図的に時差出勤をしているという話は今まで聞いたことがなかった．Slack と PagerDuty を活用してオンコールを自動化してるのは素晴らしくて，真似したいところ．質疑応答にもあったけど，各 SRE が全ての機能を把握できるわけではないため，困ったら他のメンバーに連絡して助けてもらうこともあるし，障害対応後にはドキュメントを整理して振り返ることができるようにしているとのことだった．

speakerdeck.com

cybozu.com のデータバックアップとリストア、それを活用したリハーサル @toshi_pp

サイボウズのアーキテクチャ
- マルチテナント
- マルチアプリケーション
- マルチバックエンド
ミドルウェアに依存しないようにディスクを増分バックアップして管理している
アップデートのリハーサル
- 実際にバックアップが必要になることが少なくてもリハーサルをする
- 全ては安心のため

発表を聞いていたら「独自の…」「カスタマイズした…」といった部分が多くあるらしく，運用が大変そうだなぁと客観的に感じた．復旧手順をリハーサルするのは素晴らしいと思ったし，昔 SIer で働いていたときに様々なリハーサルをしたことを思い出した．特にディザスタリカバリ系のリハーサルは「本当に起きるのかねぇ」と半信半疑だったけど，正常にフェールオーバーできたり，リストアできることの安心感は重要だと思う．まさに数日前に GitLab の障害があって，バックアップ＆リストアを見直した人も多そう．

cybozu.com のデータバックアップとリストア、それを活用したリハーサル from toshi_pp

www.slideshare.net

cookpad.com 全 HTTPS 化の軌跡 @kani_b

インフラストラクチャー部
- SRE グループ
- 社内 IT インフラグループ
- データ基盤グループ
- セキュリティグループ
今までは http と https の混在環境
なぜ HTTPS 化したのか
- セキュリティ
  - 保護できるならする
- プラットフォーム
  - ATS (iOS)
  - 検索エンジンも HTTPS を優遇する
- 新技術
  - HTTP/2
  - ServiceWorker
パフォーマンス
- TLS Handshake と暗号化のオーバーヘッドは確実に存在する
- ただ回線の高速化で体感できるほどの差ではない
検索エンジン
- 信じるしか無い
Mixed Content をひたすらに消していく
全社にアナウンスをした
- 何かあったらすぐにアラートしてくれる

「レシピサイトに暗号化が必要なのか？」という話は深かった．ユーザーがもしかしたら「閲覧したことを知られたくないかもしれない」なんて考えたことも無かったし．Windows XP も公式にサポートする姿も素晴らしかった．プラットフォームとして大きく成長して，ユーザーを第一に考えていることの証だなぁーと．

speakerdeck.com

SREグループができてこの半年間やってきたこと @isaoshimizu

XFLAG（主にモンストを運用している）
SRE はウェブオペレーション，デプロイ，モニタリングなどを担当する
オンコール当番は11名で2人ごとにローテーションしている
年末年始の対策をした
innodb_io_capacity
- レプリケーション遅延を緩和できるように
innodb_spin_wait_delay
- os_waits を減らせた
Transparent HugePages 問題
- OFF にすると良い

MySQL をカリカリにチューニングしている話で勉強になった．約1300台のサーバを管理しているって…モンストの規模大きいなぁ…！

speakerdeck.com

Arukasの運用事例と、末永くインフラ運用していくためのTips @uzyexe

“Hope is not a strategy”
見積もっていた10倍の速度でサービスが成長しているため，運用が追い付かない
オンコールは PagerDuty を使っている
プロビジョニングは Chef や Ansible を使わずに Terraform for Sacloud + CoreOS + Cloud-Config を使っている
Mesos + Marathon でリソースの制御をしている
99.999 %
- 可用性における5番目の “9” はヒューマンエラー

最近知ったんだけど Arukas って逆から読むと Sakura なんだよなー！気付いたときは驚いた．見積もった10倍で成長してしまうのは厳しい気もするけど，最終的にはビジネス的に招待予約制を導入して，成長を抑える判断になっているのは，サービスの信頼性の観点でも良いと思った．Mesos + Marathon の話は知識がなくてよく理解できなかった．

Arukasの運用事例と、末永くインフラ運用していくためのTips（SRE Tech Talks #2） from さくらインターネット株式会社

www.slideshare.net

タイミング良く無料公開となった SRE 本！まだ読めてないけど，必ず読もうと思う．SRE 本の輪読会やってる会社もあるらしく，良いなぁ！