©MIXIQAと共に築く、機能性を通じた信頼性担保への取り組み株式会社MIXI井上 翔太
View Slide
©MIXI名前：井上 翔太twitter：@syossan272019年にミクシィ（現MIXI）入社サーバーサイドを中心に開発していたが、最近はSREの実践を中心にやっていますコミュニティ活動として「ゆるSRE勉強会」ってのをやってます！！自己紹介2
©MIXI今日お話すること3
©MIXI1. はじめに2. 機能性から考える信頼性3. 機能性に対してSREが出来ること4. 実際に取り組んだこと5. まとめ4
©MIXIはじめに5
©MIXIスポーツ観戦ができる飲食店に特化した飲食店検索サービス（2021.04 リリース）サッカーはJ1~J3、野球はパ・リーグに対応！（2023年9月時点）ユーザーにとっては …スポーツ観戦できる飲食店をエリアやチーム、上映予定から検索し、予約できるお店にとっては…お店でスポーツ観戦ができることを告知し、集客することができる
©MIXIチーム構成開発チーム：７名 SREチーム：１名QAチーム：３名開発チーム：７名
©MIXIチーム構成開発チーム：７名 SREチーム：１名QAチーム：３名開発チーム：７名今回はここのお話
©MIXI機能性から考える信頼性
©MIXI「信頼性とは何ですか？」と問われた時にスッと答えることできますか？
©MIXIGoogleの答え：システムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率※※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン
©MIXIでは、この出典元である「Practical Reliability Engineering」を読んだという方はいらっしゃいますか？
©MIXIPractical Reliability Engineeringを紐解く先程の文言は工業製品における時間ベースの品質保証に関するコンテクストで語られている● 検査官が検査し、合格・不合格のみの指標でチェックしているのみでは製品の保証期間を定めることができない○ 時間を軸として「どれくらいの期間なら機能動作を保証できるのか？」といった指標が必要となった● その時間軸指標を信頼性として計算し、統計的手法を使い確率で出していきましょうというのが本書の論じているテーマ
©MIXIPractical Reliability Engineeringを紐解く先程の文言は工業製品における時間ベースの品質保証に関するコンテクストで語られている● 検査官が検査し、合格・不合格のみの指標でチェックしているのみでは製品の保証期間を定めることができない○ 時間を軸として「どれくらいの期間なら機能動作を保証できるのか？」といった指標が必要となった● その時間軸指標を信頼性として計算し、統計的手法を使い確率で出していきましょうというのが本書の論じているテーマ改めて信頼性に関する各項目を本書の文脈と合わせてみる● 求められる機能：製品がこう動くべきと事前に想定した動きをしているかどうか● 定められた条件：動作に関する事前に定義された条件● 定められた期間：算出された故障確率から設定した期間
©MIXI信頼性における機能性信頼性 = 求められる機能 × 定められた条件 × 定められた期間
©MIXI信頼性における機能性信頼性 = 求められる機能 × 定められた条件 × 定められた期間信頼性における一要素である「求められる機能」、この「機能がキチンと求められる状態になっているのか？」を担保してくれるのがQA（品質保証）である。→ つまり、QAに対してSREのプラクティスを発揮することが信頼性向上に繋がる
©MIXI信頼性における機能性信頼性 = 求められる機能 × 定められた条件 × 定められた期間信頼性における一要素である「求められる機能」、この「機能がキチンと求められる状態になっているのか？」を担保してくれるのがQA（品質保証）である。→ つまり、QAに対してSREのプラクティスを発揮することが信頼性向上に繋がるPractical Reliability Engineeringにも、こう書かれている※マネージャーやエンジニアが信頼性に影響を与えるためにどのような行動を取ることができるのでしょうか？すでに述べたように、品質保証（QA）は、納品される製品が設計に適合していることを保証するための一連の機能である。多くの製品で、QAのみで高い信頼性を確保することができるため、重要ではない単純なダイカスト（金型鋳造法での製品）を大量生産している企業が信頼性エンジニアを雇用するとは考えられません。多くの種類の製品開発や製造には、信頼性エンジニアリングの分野が存在しないのは当然のことです。ただし、QAの分野は統合された信頼性プログラム（製品やシステムの信頼性を最大化するための統合された取り組みや活動）にとって不可欠な要素です。※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用
©MIXIQAは品質保証のことだが、そもそも品質とは何か？QAにおける機能性
©MIXIQAにおける機能性QAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格
©MIXI運用・保守者に影響システムの間接利用者に影響・機能完全性・機能正確性・機能適切性QAにおける機能性機能適合性性能効率性互換性使用性信頼性 セキュリティ保守性移植性・時間効率性・資源効率性・容量満足性・共存性・相互運用性・適切度認識性・習得性・運用操作性・ユーザエラー防止性・ユーザインタフェース快美性・アクセシビリティ・成熟性・可用性・障害許容性（耐故障性）・回復性・機密性・インテグリティ・否認防止性・責任追跡性・真正性・モジュール性・再利用性・解析性・修正性・試験性・適応性・設置性・置換性システムの直接利用者に影響
©MIXIQAにおける機能性QAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格● 機能適合性：明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を,製品又はシステムが提供する度合い○ 機能完全性：機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い○ 機能正確性：正確さの必要な程度での正しい結果を、製品又はシステムが提供する度合い○ 機能適切性：明示された作業及び目的の達成を、機能が促進する度合い
©MIXIQAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格● 機能適合性：機能が利用者の要件や期待を満たし、機能が適切に動作する○ 機能完全性：提供すべき全ての機能を持っている○ 機能正確性：正確な結果や出力を提供している○ 機能適切性：利用者の要件や期待に適切に応えているQAにおける機能性
©MIXIQAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格● 機能適合性：機能が利用者の要件や期待を満たし、機能が適切に動作する○ 機能完全性：提供すべき全ての機能を持っている○ 機能正確性：正確な結果や出力を提供している○ 機能適切性：利用者の要件や期待に適切に応えている ⇒ QAの観点でも機能性は欠けてはいけない要素であることが改めてわかったQAにおける機能性
©MIXIただし、これらすべての側面よりも重要なのは、信頼性エンジニアリングの取り組みの管理です。信頼性 (そして多くの場合、安全性も ) は、現代のほとんどの工業製品にとって非常に重要なパラメータで、故障は主に関係者 (設計者・テストエンジニア・製造・サプライヤー・保守担当者・ユーザー ) によって引き起こされるものであり、トレーニング・チームワーク・規律・最適な手法の適用を含めた統合的な取り組みによって信頼性を最大化させることができます。しかし、信頼性工学の「専門家」のみでこれら統合的な取り組みの実施はできません。「専門家」はサポート・トレーニング・ツールを提供できますが、リソース管理やを組織作り、動機付け、指導することなどできるのはマネージャーだけです。 信頼性エンジニアリングは、究極的にはエンジニアリングの効果的なマネジメントなのである。 ※技術的なアプローチやツールの導入などだけではなく、マネージャーを巻き込んだエンジニアマネジメントも含めて実施することが信頼性エンジニアリングの成功に繋がる。余談：Practical Reliability Engineeringをもう少し紐解く※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用
©MIXI余談：Practical Reliability Engineeringをもう少し紐解くただし、これらすべての側面よりも重要なのは、信頼性エンジニアリングの取り組みの管理です。信頼性 (そして多くの場合、安全性も ) は、現代のほとんどの工業製品にとって非常に重要なパラメータで、故障は主に関係者 (設計者・テストエンジニア・製造・サプライヤー・保守担当者・ユーザー ) によって引き起こされるものであり、トレーニング・チームワーク・規律・最適な手法の適用を含めた統合的な取り組みによって信頼性を最大化させることができます。しかし、信頼性工学の「専門家」のみでこれら統合的な取り組みの実施はできません。「専門家」はサポート・トレーニング・ツールを提供できますが、リソース管理やを組織作り、動機付け、指導することなどできるのはマネージャーだけです。 信頼性エンジニアリングは、究極的にはエンジニアリングの効果的なマネジメントなのである。 ※技術的なアプローチやツールの導入などだけではなく、マネージャーを巻き込んだエンジニアマネジメントも含めて実施することが信頼性エンジニアリングの成功に繋がる。⇒ SRE NEXT 2023の３つの価値観の一つに「Empathy」があるが、ここではマネージャーとのコラボレーションの重要性が語られている※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用
©MIXI機能性に対してSREが出来ること
©MIXIコミュニケーションとコラボレーション！（SRE本 31章 参照）
©MIXIコミュニケーションとコラボレーション（個人的には）SREプラクティスの実践には信頼性の担保という大きな軸がありますが、それと比肩するほど大事な軸が「コミュニケーションとコラボレーション」だと考えています。SRE文化の醸成には、この「コミュニケーションとコラボレーション」が不可欠であり、必要があれば仕組み作りを行わなければなりません。
©MIXIコミュニケーションとコラボレーション（個人的には）SREプラクティスの実践には信頼性の担保という大きな軸がありますが、それと比肩するほど大事な軸が「コミュニケーションとコラボレーション」だと考えています。SRE文化の醸成には、この「コミュニケーションとコラボレーション」が不可欠であり、必要があれば仕組み作りを行わなければなりません。弊チームでの過去の実践• SREチームへの目安箱• 相談アワー⇒ 結局は日々のちょっとしたコミュニケーションの継続がコラボレーションに繋がると気付いた
©MIXIコミュニケーションとコラボレーション（個人的には）SREプラクティスの実践には信頼性の担保という大きな軸がありますが、それと比肩するほど大事な軸が「コミュニケーションとコラボレーション」だと考えています。SRE文化の醸成には、この「コミュニケーションとコラボレーション」が不可欠であり、必要があれば仕組み作りを行わなければなりません。弊チームでの過去の実践• SREチームへの目安箱• 相談アワー⇒ 結局は日々のちょっとしたコミュニケーションの継続がコラボレーションに繋がると気付いたそのような中で、QAチームとのコラボレーションが発生した
©MIXIコミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。
©MIXIコミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。⇒ ただし、技術的な観点からテストケース作成が躓くことが多く、協力してほしいとのお言葉を頂いた
©MIXIコミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。⇒ ただし、技術的な観点からテストケース作成が躓くことが多く、協力してほしいとのお言葉を頂いた＿人人人人人人人人人人人人人＿＞ コラボレーションの発生 ＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣
©MIXIコミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。⇒ ただし、技術的な観点からテストケース作成が躓くことが多く、協力してほしいとのお言葉を頂いた＿人人人人人人人人人人人人人＿＞ コラボレーションの発生 ＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣今までは開発チームとのコラボレーションにばかり目が向いていたが、他チームにも向けないといけなかったなと反省
©MIXI実際に取り組んだこと
©MIXI● E2E支援● QAテスト支援ツールの作成
©MIXI何事もまずは対話から！ということで、QAチームに現況とSREチームに何を期待しているのか？をヒアリング。進め方
©MIXI何事もまずは対話から！ということで、QAチームに現況とSREチームに何を期待しているのか？をヒアリング。⇒ ヒアリングした結果、QAチームではエンジニアリングに長けた方がいないので、E2Eテストの作成で躓くことがあり、なかなか進捗が芳しくないとのこと。SREチームとしては技術観点でのアドバイスやサポートを提案し、QAチームとの合意も取れた進め方
©MIXI何事もまずは対話から！ということで、QAチームに現況とSREチームに何を期待しているのか？をヒアリング。⇒ ヒアリングした結果、QAチームではエンジニアリングに長けた方がいないので、E2Eテストの作成で躓くことがあり、なかなか進捗が芳しくないとのこと。SREチームとしては技術観点でのアドバイスやサポートを提案し、QAチームとの合意も取れたヒアリングの中で「QAメンバーの成長機会を奪わないようサポートして欲しい」というお声も頂いたので、以下のようなことをエンゲージメントモデルとして定めた。● テストケースはこちらで作成しない● サービス側に手を加える必要が出た場合にコード・データ修正等の対応● なるたけ具体的な答えを提示しないようアドバイス● エンジニアならではの言い回し・言葉などをなるべく避けるようにやり取りまた、進捗報告や作業に齟齬が発生しないように毎週定期MTGを行った。進め方
©MIXIE2Eの支援では以下のようなことを実施しました。• 動いていたテストケースが動かなくなった時のサービス側調査• Firebase AuthでのreCAPTCHA突破対応• 開発・ステージング環境で利用しているIAPについての説明・対応方法のアドバイス• Gmail Web APIを利用したメール認証突破におけるアドバイス• MagicPod側のバグ調査・問い合わせ対応• etc…E2E支援
©MIXI● 新規登録・ログイン時にFirebase Authを利用している● 最初は要素のクリックなどステップ毎に待機時間を設けるなどアナログな方法で突破していた● ある日、急にreCAPTCHAでbot判定を喰らうように・・・● Magic Podで設定している固定IPを判定し、サービス側でreCAPTCHAをスキップするように対応E2E支援 - Firebase AuthでのreCAPTCHA突破対応 -
©MIXIE2Eの支援では以下のようなことを実施しました。⇒ 改めて対応したことを振り返ってみると、エンジニアの介入無しにはなかなか対応し辛い問題ばかり⇒タスクのインパクトが低いものについては爆速で解決することを心掛け、QAチームからの信頼貯金を貯める● 動いていたテストケースが動かなくなった時のサービス側調査● Firebase AuthでのreCAPTCHA突破対応● 開発・ステージング環境で利用しているIAPについての説明・対応方法のアドバイス● Gmail Web APIを利用したメール認証突破におけるアドバイス● MagicPod側のバグ調査・問い合わせ対応● etc…E2E支援
©MIXIQAテスト支援ツールの作成E2E支援を継続的に行っていたが、どうしても手動確認しなければならないテストケースが存在していた。そういった毎回発生する手動の辛み（=トイル）を少しでも軽減するためにQAチームとの協議のもとデバッグツールの作成を進めることに。
©MIXIQAテスト支援ツールの作成E2E支援を継続的に行っていたが、どうしても手動確認しなければならないテストケースが存在していた。そういった毎回発生する手動の辛み（=トイル）を少しでも軽減するためにQAチームとの協議のもとデバッグツールの作成を進めることに。こちらもE2Eの時と同様にまずはヒアリングを行い、どういった手作業が発生し辛みはどこにあるのか？を聞き出すところから実施しました。• 店舗レーティングの追加・編集• ユーザーレーティングの追加・編集• 予約の追加・編集• 店舗の追加・編集• QA環境が複数あるため、各環境の切り替え機能
©MIXIQAテスト支援ツールの作成
©MIXIQAテスト支援ツールの作成E2E支援を継続的に行っていたが、どうしても手動確認しなければならないテストケースが存在していた。そういった毎回発生する手動の辛み（=トイル）を少しでも軽減するためにQAチームとの協議のもとデバッグツールの作成を進めることに。こちらもE2Eの時と同様にまずはヒアリングを行い、どういった手作業が発生し辛みはどこにあるのか？などを聞くところから実施しました。⇒ E2Eテストなど自動テストが拡充されていない場合、QA作業はトイルの宝庫（？）もしそういった現場にいる方はQAチームに声をかけてトイル撲滅活動していきましょう！• 店舗レーティングの追加・編集• ユーザーレーティングの追加・編集• 予約の追加・編集• 店舗の追加・編集• QA環境が複数あるため、各環境の切り替え機能
©MIXIまとめ
©MIXI発表聞いてどう感じました？
©MIXI正直、「コラボレーションって言ってる割に大した事やってなくない？」って思ったりしませんでした？
©MIXIそうなんです、気合いを入れて“凄い事”をやろうとしなくてもいいのです。マーケティングのドリルの穴理論のように、コラボレーション先が求めている結果が達成できるのならばどのような方法でも良いのです。どう感じました？
©MIXIそうなんです、気合いを入れて“凄い事”をやろうとしなくてもいいのです。マーケティングのドリルの穴理論のように、コラボレーション先が求めている結果が達成できるのならばどのような方法でも良いのです。SRE本の著者の一人であるNiall Murphy氏は以下のようなことを仰っておりました。※これはまさに、な例ですね。コラボ相手・またSREを実践しているチームにとっても時間は非常に重要なリソースです。その貴重な時間を守るためにも、「どのような結果を求めているのか？」「こちらから提案できる別の結果の形はあるのか？」など対話を密にすることによって最適な解を探っていきましょう。どう感じました？SSHしてコマンドを叩き、本番環境デプロイするというフローを採用していた企業から「より良いデプロイフローを設計し、実装してほしい」と頼まれた。私は当初、k8sを用いたデプロイメントフローを構築しようとしていましたが一ヶ月は掛かる予定でした。しかし、設計を２度やり直した結果、Ruby on Railsで用意したURLにアクセスするとデプロイコマンドが走るように作成することとなり、最終的な工数は設計：３日と実装：３時間でした。※ Niall Murphy (2023年) SRE in the Real World - https://blog.relyabilit.ie/sre-in-the-real-world/ より引用
©MIXI皆さんはどうですか？他のチームとのコラボレーション、皆さんは出来ていますでしょうか？もし出来ていない場合、何が原因でしょうか？
©MIXI皆さんはどうですか？他のチームとのコラボレーション、皆さんは出来ていますでしょうか？もし出来ていない場合、何が原因でしょうか？こういったことを考えることはテクニカルな話からは遠く、もしかすると疎む方すらいるかもしれません。しかし、SREは総合格闘技のようなものでテッキーなだけでは偏った実践しかできません。また大事な考え方として、「信頼性は一人では得ることはできない、全員で勝ち得るもの」というものが自分の中にあります。もし、一人で勝ち得ていると思っていても、もしかするとその裏で上手くいくように気付かれず尽力してくれている人がいるかもしれません。
©MIXI皆さんはどうですか？他のチームとのコラボレーション、皆さんは出来ていますでしょうか？もし出来ていない場合、何が原因でしょうか？こういったことを考えることはテクニカルな話からは遠く、もしかすると疎む方すらいるかもしれません。しかし、SREは総合格闘技のようなものでテッキーなだけでは偏った実践しかできません。また大事な考え方として、「信頼性は一人では得ることはできない、全員で勝ち得るもの」というものが自分の中にあります。もし、一人で勝ち得ていると思っていても、もしかするとその裏で上手くいくように気付かれず尽力してくれている人がいるかもしれません。また、初めからコラボレーションと身構えて行動するより“些細な手助け”から始めるのも良いでしょう。Niall Murphy氏の言葉を借りると「SREプラクティスを超えて、手助けをすることから始めることもお勧めする※」とあるので、コラボレーションの練習と信頼貯金を貯めることを兼ねて困っている人を見かけたら手助けしてみましょう※ Niall Murphy (2023年) SRE in the Real World - https://blog.relyabilit.ie/sre-in-the-real-world/ より引用
©MIXI良いSREライフを！ご清聴ありがとうございました！！
syossan27
jrom
moore
jonrohan
addyosmani
matthewcrist
brianwarren
zakiwarfel
wjessup
chrislema
schacon