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

Transcript

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