QAと共に築く、機能性を通じた信頼性担保への取り組み

by syossan27

Slide 1

Slide 1 text

©MIXI QAと共に築く、機能性を通じた信頼性担保への取り組み株式会社MIXI 井上翔太

Slide 2

Slide 2 text

©MIXI 名前：井上翔太 twitter：@syossan27 2019年にミクシィ（現MIXI）入社サーバーサイドを中心に開発していたが、最近は SREの実践を中心にやっていますコミュニティ活動として「ゆるSRE勉強会」ってのをやってます！！自己紹介 2

Slide 3

Slide 3 text

©MIXI 今日お話すること 3

Slide 4

Slide 4 text

©MIXI 1. はじめに 2. 機能性から考える信頼性 3. 機能性に対してSREが出来ること 4. 実際に取り組んだこと 5. まとめ 4

Slide 5

Slide 5 text

©MIXI はじめに 5

Slide 6

Slide 6 text

©MIXI スポーツ観戦ができる飲食店に特化した飲食店検索サービス（2021.04 リリース）サッカーはJ1~J3、野球はパ・リーグに対応！（2023年9月時点）ユーザーにとっては … スポーツ観戦できる飲食店をエリアやチーム、上映予定から検索し、予約できるお店にとっては… お店でスポーツ観戦ができることを告知し、集客することができる

Slide 7

Slide 7 text

©MIXI チーム構成開発チーム：７名 SREチーム：１名 QAチーム：３名開発チーム：７名

Slide 8

Slide 8 text

©MIXI チーム構成開発チーム：７名 SREチーム：１名 QAチーム：３名開発チーム：７名今回はここのお話

Slide 9

Slide 9 text

©MIXI 機能性から考える信頼性

Slide 10

Slide 10 text

©MIXI 「信頼性とは何ですか？」と問われた時にスッと答えることできますか？

Slide 11

Slide 11 text

©MIXI Googleの答え：システムが求められる機能を、定められた条件の下で、定められた期間にわたり、障害を起こすことなく実行する確率※ ※ Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン

Slide 12

Slide 12 text

©MIXI では、この出典元である「Practical Reliability Engineering」を読んだという方はいらっしゃいますか？

Slide 13

Slide 13 text

Slide 14

Slide 14 text

©MIXI Practical Reliability Engineeringを紐解く先程の文言は工業製品における時間ベースの品質保証に関するコンテクストで語られている ● 検査官が検査し、合格・不合格のみの指標でチェックしているのみでは製品の保証期間を定めることができない ○ 時間を軸として「どれくらいの期間なら機能動作を保証できるのか？」といった指標が必要となった ● その時間軸指標を信頼性として計算し、統計的手法を使い確率で出していきましょうというのが本書の論じているテーマ改めて信頼性に関する各項目を本書の文脈と合わせてみる ● 求められる機能：製品がこう動くべきと事前に想定した動きをしているかどうか ● 定められた条件：動作に関する事前に定義された条件 ● 定められた期間：算出された故障確率から設定した期間

Slide 15

Slide 15 text

©MIXI 信頼性における機能性信頼性 = 求められる機能 × 定められた条件 × 定められた期間

Slide 16

Slide 16 text

Slide 17

Slide 17 text

©MIXI 信頼性における機能性信頼性 = 求められる機能 × 定められた条件 × 定められた期間信頼性における一要素である「求められる機能」、この「機能がキチンと求められる状態になっているのか？」を担保してくれるのがQA（品質保証）である。 → つまり、QAに対してSREのプラクティスを発揮することが信頼性向上に繋がる Practical Reliability Engineeringにも、こう書かれている※ マネージャーやエンジニアが信頼性に影響を与えるためにどのような行動を取ることができるのでしょうか？すでに述べたように、品質保証（QA）は、納品される製品が設計に適合していることを保証するための一連の機能である。多くの製品で、QAのみで高い信頼性を確保することができるため、重要ではない単純なダイカスト（金型鋳造法での製品）を大量生産している企業が信頼性エンジニアを雇用するとは考えられません。多くの種類の製品開発や製造には、信頼性エンジニアリングの分野が存在しないのは当然のことです。ただし、QAの分野は統合された信頼性プログラム（製品やシステムの信頼性を最大化するための統合された取り組みや活動）にとって不可欠な要素です。 ※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用

Slide 18

Slide 18 text

©MIXI QAは品質保証のことだが、そもそも品質とは何か？ QAにおける機能性

Slide 19

Slide 19 text

©MIXI QAにおける機能性 QAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格

Slide 20

Slide 20 text

©MIXI 運用・保守者に影響システムの間接利用者に影響・機能完全性・機能正確性・機能適切性 QAにおける機能性機能適合性性能効率性互換性使用性信頼性セキュリティ保守性移植性・時間効率性・資源効率性・容量満足性・共存性・相互運用性・適切度認識性・習得性・運用操作性・ユーザエラー防止性・ユーザインタフェース快美性・アクセシビリティ・成熟性・可用性・障害許容性（耐故障性）・回復性・機密性・インテグリティ・否認防止性・責任追跡性・真正性・モジュール性・再利用性・解析性・修正性・試験性・適応性・設置性・置換性システムの直接利用者に影響

Slide 21

Slide 21 text

Slide 22

Slide 22 text

©MIXI QAにおける機能性 QAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格 ● 機能適合性：明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を ,製品又はシステムが提供する度合い ○ 機能完全性：機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い ○ 機能正確性：正確さの必要な程度での正しい結果を、製品又はシステムが提供する度合い ○ 機能適切性：明示された作業及び目的の達成を、機能が促進する度合い

Slide 23

Slide 23 text

Slide 24

Slide 24 text

©MIXI QAは品質保証のことだが、そもそも品質とは何か？システム及びソフトウェア品質モデル（ISO/IEC 25010）システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格 ● 機能適合性：機能が利用者の要件や期待を満たし、機能が適切に動作する ○ 機能完全性：提供すべき全ての機能を持っている ○ 機能正確性：正確な結果や出力を提供している ○ 機能適切性：利用者の要件や期待に適切に応えている QAにおける機能性

Slide 25

Slide 25 text

Slide 26

Slide 26 text

©MIXI ただし、これらすべての側面よりも重要なのは、信頼性エンジニアリングの取り組みの管理です。信頼性 (そして多くの場合、安全性も ) は、現代のほとんどの工業製品にとって非常に重要なパラメータで、故障は主に関係者 (設計者・テストエンジニア・製造・サプライヤー・保守担当者・ユーザー ) によって引き起こされるものであり、トレーニング・チームワーク・規律・最適な手法の適用を含めた統合的な取り組みによって信頼性を最大化させることができます。しかし、信頼性工学の「専門家」のみでこれら統合的な取り組みの実施はできません。「専門家」はサポート・トレーニング・ツールを提供できますが、リソース管理やを組織作り、動機付け、指導することなどできるのはマネージャーだけです。信頼性エンジニアリングは、究極的にはエンジニアリングの効果的なマネジメントなのである。 ※ 技術的なアプローチやツールの導入などだけではなく、マネージャーを巻き込んだエンジニアマネジメントも含めて実施することが信頼性エンジニアリングの成功に繋がる。余談：Practical Reliability Engineeringをもう少し紐解く ※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用

Slide 27

Slide 27 text

©MIXI 余談：Practical Reliability Engineeringをもう少し紐解くただし、これらすべての側面よりも重要なのは、信頼性エンジニアリングの取り組みの管理です。信頼性 (そして多くの場合、安全性も ) は、現代のほとんどの工業製品にとって非常に重要なパラメータで、故障は主に関係者 (設計者・テストエンジニア・製造・サプライヤー・保守担当者・ユーザー ) によって引き起こされるものであり、トレーニング・チームワーク・規律・最適な手法の適用を含めた統合的な取り組みによって信頼性を最大化させることができます。しかし、信頼性工学の「専門家」のみでこれら統合的な取り組みの実施はできません。「専門家」はサポート・トレーニング・ツールを提供できますが、リソース管理やを組織作り、動機付け、指導することなどできるのはマネージャーだけです。信頼性エンジニアリングは、究極的にはエンジニアリングの効果的なマネジメントなのである。 ※ 技術的なアプローチやツールの導入などだけではなく、マネージャーを巻き込んだエンジニアマネジメントも含めて実施することが信頼性エンジニアリングの成功に繋がる。 ⇒ SRE NEXT 2023の３つの価値観の一つに「Empathy」があるが、ここではマネージャーとのコラボレーションの重要性が語られている ※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用

Slide 28

Slide 28 text

©MIXI 機能性に対してSREが出来ること

Slide 29

Slide 29 text

©MIXI コミュニケーションとコラボレーション！（SRE本 31章参照）

Slide 30

Slide 30 text

Slide 31

Slide 31 text

©MIXI コミュニケーションとコラボレーション（個人的には）SREプラクティスの実践には信頼性の担保という大きな軸がありますが、それと比肩するほど大事な軸が「コミュニケーションとコラボレーション」だと考えています。 SRE文化の醸成には、この「コミュニケーションとコラボレーション」が不可欠であり、必要があれば仕組み作りを行わなければなりません。弊チームでの過去の実践 • SREチームへの目安箱 • 相談アワー ⇒ 結局は日々のちょっとしたコミュニケーションの継続がコラボレーションに繋がると気付いた

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©MIXI コミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。

Slide 34

Slide 34 text

©MIXI コミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。 ⇒ ただし、技術的な観点からテストケース作成が躓くことが多く、協力してほしいとのお言葉を頂いた

Slide 35

Slide 35 text

©MIXI コミュニケーションとコラボレーション当時、QAチームでは網羅的なテストシナリオを手動で実行していたが、MagicPodを導入しE2Eでの自動テストを拡充させようとしている状況でありました。 ⇒ ただし、技術的な観点からテストケース作成が躓くことが多く、協力してほしいとのお言葉を頂いた＿人人人人人人人人人人人人人＿＞　コラボレーションの発生　＜￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

Slide 36

Slide 36 text

Slide 37

Slide 37 text

©MIXI 実際に取り組んだこと

Slide 38

Slide 38 text

©MIXI ● E2E支援 ● QAテスト支援ツールの作成

Slide 39

Slide 39 text

©MIXI 何事もまずは対話から！ということで、QAチームに現況とSREチームに何を期待しているのか？をヒアリング。進め方

Slide 40

Slide 40 text

Slide 41

Slide 41 text

©MIXI 何事もまずは対話から！ということで、QAチームに現況とSREチームに何を期待しているのか？をヒアリング。 ⇒ ヒアリングした結果、QAチームではエンジニアリングに長けた方がいないので、E2Eテストの作成で躓くことがあり、なかなか進捗が芳しくないとのこと。 SREチームとしては技術観点でのアドバイスやサポートを提案し、QAチームとの合意も取れたヒアリングの中で「QAメンバーの成長機会を奪わないようサポートして欲しい」というお声も頂いたので、以下のようなことをエンゲージメントモデルとして定めた。 ● テストケースはこちらで作成しない ● サービス側に手を加える必要が出た場合にコード・データ修正等の対応 ● なるたけ具体的な答えを提示しないようアドバイス ● エンジニアならではの言い回し・言葉などをなるべく避けるようにやり取りまた、進捗報告や作業に齟齬が発生しないように毎週定期MTGを行った。進め方

Slide 42

Slide 42 text

©MIXI E2Eの支援では以下のようなことを実施しました。 • 動いていたテストケースが動かなくなった時のサービス側調査 • Firebase AuthでのreCAPTCHA突破対応 • 開発・ステージング環境で利用しているIAPについての説明・対応方法のアドバイス • Gmail Web APIを利用したメール認証突破におけるアドバイス • MagicPod側のバグ調査・問い合わせ対応 • etc… E2E支援

Slide 43

Slide 43 text

©MIXI ● 新規登録・ログイン時にFirebase Authを利用している ● 最初は要素のクリックなどステップ毎に待機時間を設けるなどアナログな方法で突破していた ● ある日、急にreCAPTCHAでbot判定を喰らうように・・・ ● Magic Podで設定している固定IPを判定し、サービス側でreCAPTCHAをスキップするように対応 E2E支援 - Firebase AuthでのreCAPTCHA突破対応 -

Slide 44

Slide 44 text

©MIXI E2Eの支援では以下のようなことを実施しました。 ⇒ 改めて対応したことを振り返ってみると、エンジニアの介入無しにはなかなか対応し辛い問題ばかり ⇒タスクのインパクトが低いものについては爆速で解決することを心掛け、QAチームからの信頼貯金を貯める ● 動いていたテストケースが動かなくなった時のサービス側調査 ● Firebase AuthでのreCAPTCHA突破対応 ● 開発・ステージング環境で利用しているIAPについての説明・対応方法のアドバイス ● Gmail Web APIを利用したメール認証突破におけるアドバイス ● MagicPod側のバグ調査・問い合わせ対応 ● etc… E2E支援

Slide 45

Slide 45 text

©MIXI QAテスト支援ツールの作成 E2E支援を継続的に行っていたが、どうしても手動確認しなければならないテストケースが存在していた。そういった毎回発生する手動の辛み（=トイル）を少しでも軽減するためにQAチームとの協議のもとデバッグツールの作成を進めることに。

Slide 46

Slide 46 text

©MIXI QAテスト支援ツールの作成 E2E支援を継続的に行っていたが、どうしても手動確認しなければならないテストケースが存在していた。そういった毎回発生する手動の辛み（=トイル）を少しでも軽減するためにQAチームとの協議のもとデバッグツールの作成を進めることに。こちらもE2Eの時と同様にまずはヒアリングを行い、どういった手作業が発生し辛みはどこにあるのか？を聞き出すところから実施しました。 • 店舗レーティングの追加・編集 • ユーザーレーティングの追加・編集 • 予約の追加・編集 • 店舗の追加・編集 • QA環境が複数あるため、各環境の切り替え機能

Slide 47

Slide 47 text

Slide 48

Slide 48 text

©MIXI QAテスト支援ツールの作成 E2E支援を継続的に行っていたが、どうしても手動確認しなければならないテストケースが存在していた。そういった毎回発生する手動の辛み（=トイル）を少しでも軽減するためにQAチームとの協議のもとデバッグツールの作成を進めることに。こちらもE2Eの時と同様にまずはヒアリングを行い、どういった手作業が発生し辛みはどこにあるのか？などを聞くところから実施しました。 ⇒ E2Eテストなど自動テストが拡充されていない場合、QA作業はトイルの宝庫（？）もしそういった現場にいる方はQAチームに声をかけてトイル撲滅活動していきましょう！ • 店舗レーティングの追加・編集 • ユーザーレーティングの追加・編集 • 予約の追加・編集 • 店舗の追加・編集 • QA環境が複数あるため、各環境の切り替え機能

Slide 49

Slide 49 text

©MIXI まとめ

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

©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/ より引用

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

©MIXI 皆さんはどうですか？他のチームとのコラボレーション、皆さんは出来ていますでしょうか？もし出来ていない場合、何が原因でしょうか？こういったことを考えることはテクニカルな話からは遠く、もしかすると疎む方すらいるかもしれません。しかし、SREは総合格闘技のようなものでテッキーなだけでは偏った実践しかできません。また大事な考え方として、「信頼性は一人では得ることはできない、全員で勝ち得るもの」というものが自分の中にあります。もし、一人で勝ち得ていると思っていても、もしかするとその裏で上手くいくように気付かれず尽力してくれている人がいるかもしれません。また、初めからコラボレーションと身構えて行動するより“些細な手助け”から始めるのも良いでしょう。Niall Murphy氏の言葉を借りると「SREプラクティスを超えて、手助けをすることから始めることもお勧めする※」とあるので、コラボレーションの練習と信頼貯金を貯めることを兼ねて困っている人を見かけたら手助けしてみましょう ※ Niall Murphy (2023年) SRE in the Real World - https://blog.relyabilit.ie/sre-in-the-real-world/ より引用