日経電子版SREチーム立ち上げ中

by osamunmun

Slide 1

Slide 1 text

日経電子版SREチーム立ち上げ中日本経済新聞社髙安伯武 SRE NEXT 2020 IN TOKYO #srenextA #srenext 1

Slide 2

Slide 2 text

● 名前 ○ 髙安伯武(Takayasu Osamu) ○ @osamunmun ● 所属 ○ 日本経済新聞社デジタル編成ユニット ● やっていること ○ 日経電子版の開発 ○ 最近は、技術戦略、エンジニア組織作りなどがメイン about me 2

Slide 3

Slide 3 text

• 2010/3月サービスローンチ • 有料ユーザー60万人以上 • 月4,277円のサブスクリプションモデル • 毎日約1,000記事を配信 • API 2,000req/sec 日経電子版 3

Slide 4

Slide 4 text

アジェンダ 1. SRE立ち上げ前の状況(2018年) 2. 何が課題だったのか 3. SREチーム結成 4. できなかったこと/できたこと 5. 今後の取り組み 4

Slide 5

Slide 5 text

1. SRE立ち上げ前の状況(2018年) 5

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

チーム体制概略図各開発チームの役割 Infra ServiceA Prometheus Grafana ServiceB Deploy Pipeline Infra ServiceC ES Kibana Logging Monitoring Availability... Deploy Pipeline Logging Monitoring Availability... ● 各チームがそれぞれインフラ〜アプリ、機能開発〜運用を頑張っている ● 内製/外注開発チームがある・・・ 9

Slide 10

Slide 10 text

Takeaway ● 内製開発チーム、外注開発チームが混在する ● 各チームが縦割りで閉じて各システムを開発、運用する ● モダンなシステム、レガシーなシステムが混在するこういう組織でどうやって横断的にSREを実践していくのか 10

Slide 11

Slide 11 text

2. 何が課題だったのか 11

Slide 12

Slide 12 text

何が課題だったのか a. サービスレベルがバラバラ b. システムの安定性が後回しにされがち c. 事業成長の足枷になるリスク 12

Slide 13

Slide 13 text

チーム体制概略図 BFF for Mobile Web (r.nikkei.com) BFF for Native App (iOS/Android) PC System (www.nikkei.com) APIGateway NikkeiID Billing System APIs(MicroServices) search paper image save articles ….. Data Platform CMS for Digital Mail System Ads System Fastly a.サービスレベルがバラバラ創刊時からあるシステム比較的新しいシステム ● 5人で運用 ● 障害を5分以内に検知 ● 2人で運用 ● 障害検知に30分 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

b. システムの安定性が後回しにされがち ● 機能開発〜運用を一つのチームが担当 ● 事業への貢献度が見えやすい機能開発が優先されがち。安定性の向上へのタスクの優先度が上がらない安定性向上機能開発事業成長ユーザー増/利益増 15

Slide 16

Slide 16 text

● 電子版の進化を加速したい ● 電子版以外のデジタルサービスもどんどんチャレンジしたい c. 事業成長の足枷になるリスク ● 技術スタックがバラバラ、属人化が進んでいて柔軟にアサインできない ● 新規にサービスを立ち上げるたびにシステムを0から検討しないといけない 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

3. SREチーム結成 18

Slide 19

Slide 19 text

SREチーム SREチーム APIチームモバイルWeb チームデータチーム兼務 ● 責務 ○ 電子版全体の「安定性」と「アーキテクチャ」に責任を持つ ● 特徴 ○ 既存システムのオペレーション業務を持ってない ○ 全員SRE未経験者電子版に関わるエンジニアは約50名・・・ 19

Slide 20

Slide 20 text

4. できなかったこと/できたこと 20

Slide 21

Slide 21 text

できなかったこと 21

Slide 22

Slide 22 text

SLI/SLOの設定 22

Slide 23

Slide 23 text

最初に何から手を付けるか Objective: 電子版の可用性と信頼性がコントラールブルになっている! ● まずは、今の電子版の可用性、信頼性を把握しないと始まらない ● SLI/SLOの設定と計測から着手 23

Slide 24

Slide 24 text

SLI/SLOの設定にチャレンジするものの... ● すべてのAPIにSLI/SLOを！ ○ internalなapiも含めるとAPIたくさん... ○ pathによってSLO変わってくるのでは...? ○ アクセスログの保管場所が散らばってるシステムも... ■ システム自体に手を入れないと... ● リクエストベースでのSLI/SLOへの固執 ○ 細かく設定しないとサービスレベルを測れないという思い込み ○ 個別に設定しようとして途方に暮れる 24

Slide 25

Slide 25 text

SLI/SLOの設定にチャレンジするものの... ● やっていることが本当に意味のあることか疑い始める ○ モチベーションの低下 ● 度重なる障害対応 ○ こっちを先になんとかしないと... ● 具体的な成果がイメージできる課題の誘惑 ○ デプロイ速度遅い問題 ○ アーキテクチャ刷新 25

Slide 26

Slide 26 text

SLI/SLOから逃避した... 26

Slide 27

Slide 27 text

SLI/SLOの設定反省 ● もっとシンプルに考えればよかったのでは ○ 時間ベースの稼働率でスタートすれば良かった ■ 各リクエストベースよりは測りやすい ○ 設定した指標で漏れがあればSLIを追加 ○ より信頼性の解像度を上げる必要が出てきてから細分化 27

Slide 28

Slide 28 text

できたこと 28

Slide 29

Slide 29 text

組織内での啓蒙活動 29

Slide 30

Slide 30 text

SREチーム発足時の組織的状況 SREチーム内製開発チーム・・・非エンジニアのマネージャーレガシーシステムのチーム非エンジニアのメンバー ● 困ってない。あんまり関心ない ● 一部メンバーはSREチームにコミット ● 楽になるのか？ ● 様子見 ● SREのことを知らない ● 解決しようとしている課題もよくわからない ● SREのことを知らない ● 解決しようとしている課題もよくわからない 30

Slide 31

Slide 31 text

SREチーム発足後内製開発チーム・・・非エンジニアのマネージャーレガシーシステムのチーム非エンジニアのメンバー障害頻発ペインペイン SREチーム啓蒙啓蒙障害対応、改善をサポートリアーキテクチャ、改善に一緒に取り組む 31

Slide 32

Slide 32 text

現在のSREチームの立ち位置内製開発チーム・・・非エンジニアのマネージャーレガシーシステムのチーム非エンジニアのメンバー SREチーム期待理解リアーキテクチャの相談、協働相談、依頼 ● SREのことを知らない ● 解決しようとしている課題もよくわからない ● 解決しようとしている課題と重要性を理解 32

Slide 33

Slide 33 text

障害対応プロセスの改善 33

Slide 34

Slide 34 text

障害対応プロセスの改善 ● 障害対応時のコミュニケーション ○ Slackのopenなチャンネルでやりとり ○ リモートからSlackで連携しながら障害対応する訓練の実施 ● 各チーム内に閉じていた障害のふりかえりへの参加 ○ 担当チームとポストモーテムを書く ○ 改善アクションを協働 ● 障害報告フォーマットの統一化、集約 34

Slide 35

Slide 35 text

電子版全体のアーキテクチャ検討、改善 35

Slide 36

Slide 36 text

● Mobile WebのBFFをリアーキテクチャ ○ デプロイ速度と運用の複雑さが課題になっていた ● 固有の課題の解決だけではなく他システムにも適用できるようなリファレンスアーキテクチャを念頭において設計 ● アーキテクチャの統一のための技術投資的な側面電子版全体のアーキテクチャ検討、改善 AWS ElasticBeanstalk Google Kubernetes Engine 36

Slide 37

Slide 37 text

1年やってみて... 37

Slide 38

Slide 38 text

コレはSREなのだろうか？ 38

Slide 39

Slide 39 text

システム横断でDevOpsチームとして動けたが... ● 結局SLI/SLOを運用できてない ○ 信頼性を計測できてない ○ 計測できていないから制御できているかもわからない ● 啓蒙活動と各システムの改善を通して、組織内でのSREチームのプレゼンスは上がってきた 39

Slide 40

Slide 40 text

5. 今後の取り組み 40

Slide 41

Slide 41 text

もう一度SLI/SLOに向き合おう 41

Slide 42

Slide 42 text

今後の取り組み ● SLI/SLOに再チャレンジ ○ 前回の反省をもとに稼働率を使うところから ○ チームのプレゼンスは上がってきた ■ 各チームと協力して動けるようになってきた ○ レガシーシステムがクラウド移行するタイミング 42

Slide 43

Slide 43 text

日経はエンジニアの仲間を募集中 ● SREチームは中途/フリーランスどちらも募集中 ● エンジニアが1名ジョインすることの効果がとても大きい状況 ● Techブログ ○ https://hack.nikkei.com/ ● エンジニア向けTwitter ○ @nikkeideveloper ○ DMお待ちしてます ● オフィス見学歓迎 43