Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

syossan27
September 29, 2023
5.1k

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

syossan27

September 29, 2023
Tweet

Transcript

  1. ©MIXI Googleの答え: システムが求められる機能を、定められた条件の下で、 定められた期間にわたり、障害を起こすことなく実行する確率※ ※ Betsy Beyer, Chris Jones, Jennifer

    Petoff, Niall Richard Murphy (2017年) SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム- オライリージャパン
  2. ©MIXI Practical Reliability Engineeringを紐解く 先程の文言は工業製品における時間ベースの品質保証に関するコンテクストで語られている • 検査官が検査し、合格・不合格のみの指標でチェックしているのみでは製品の保証期間を定めるこ とができない ◦ 時間を軸として「どれくらいの期間なら機能動作を保証できるのか?」といった指標が必要となった

    • その時間軸指標を信頼性として計算し、統計的手法を使い確率で出していきましょう というのが本書の論じているテーマ 改めて信頼性に関する各項目を本書の文脈と合わせてみる • 求められる機能:製品がこう動くべきと事前に想定した動きをしているかどうか • 定められた条件:動作に関する事前に定義された条件 • 定められた期間:算出された故障確率から設定した期間
  3. ©MIXI 信頼性における機能性 信頼性 = 求められる機能 × 定められた条件 × 定められた期間 信頼性における一要素である「求められる機能」、この「機能がキチンと求められる状態になっているの

    か?」を担保してくれるのがQA(品質保証)である。 → つまり、QAに対してSREのプラクティスを発揮することが信頼性向上に繋がる
  4. ©MIXI 信頼性における機能性 信頼性 = 求められる機能 × 定められた条件 × 定められた期間 信頼性における一要素である「求められる機能」、この「機能がキチンと求められる状態になっているの

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

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

    使用性 信頼性 セキュリティ 保守性 移植性 ・時間効率性 ・資源効率性 ・容量満足性 ・共存性 ・相互運用性 ・適切度認識性 ・習得性 ・運用操作性 ・ユーザエラー防止性 ・ユーザインタフェース快美性 ・アクセシビリティ ・成熟性 ・可用性 ・障害許容性(耐故障性) ・回復性 ・機密性 ・インテグリティ ・否認防止性 ・責任追跡性 ・真正性 ・モジュール性 ・再利用性 ・解析性 ・修正性 ・試験性 ・適応性 ・設置性 ・置換性 システムの直接利用者に影響
  7. ©MIXI QAにおける機能性 QAは品質保証のことだが、そもそも品質とは何か? システム及びソフトウェア品質モデル(ISO/IEC 25010) システム、ソフトウェアの品質特性を定義し、品質の評価の際に用いられる国際標準規格 • 機能適合性:明示された状況下で使用するとき、明示的ニーズ及び暗黙のニーズを満足させる機能を ,製品又はシス テムが提供する度合い

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

    ◦ 機能完全性:機能の集合が明示された作業及び利用者の目的の全てを網羅する度合い ◦ 機能正確性:正確さの必要な程度での正しい結果を、製品又はシステムが提供する度合い ◦ 機能適切性:明示された作業及び目的の達成を、機能が促進する度合い
  9. ©MIXI ただし、これらすべての側面よりも重要なのは、信頼性エンジニアリングの取り組みの管理です。 信頼性 (そして多くの場合、安全性も ) は、現代のほとんどの工業製品にとって非常に重要なパラメータで、故障は主に関係者 (設計者・テスト エンジニア・製造・サプライヤー・保守担当者・ユーザー ) によって引き起こされるものであり、トレーニング・チームワーク・規律・最適な手法の

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

    エンジニア・製造・サプライヤー・保守担当者・ユーザー ) によって引き起こされるものであり、トレーニング・チームワーク・規律・最適な手法の 適用を含めた統合的な取り組みによって信頼性を最大化させることができます。 しかし、信頼性工学の「専門家」のみでこれら統合的な取り組みの実施はできません。 「専門家」はサポート・トレーニング・ツールを提供できますが、リソース管理やを組織作り、動機付け、指導することなどできるのはマネー ジャーだけです。 信頼性エンジニアリングは、究極的にはエンジニアリングの効果的なマネジメントなのである。 ※ 技術的なアプローチやツールの導入などだけではなく、マネージャーを巻き込んだエンジニアマネジメン トも含めて実施することが信頼性エンジニアリングの成功に繋がる。 ⇒ SRE NEXT 2023の3つの価値観の一つに「Empathy」があるが、ここではマネージャーとのコラボ レーションの重要性が語られている ※ Patrick D. T. O'Connor (2012年) Practical Reliability Engineering, 5th Edition より引用
  11. ©MIXI そうなんです、気合いを入れて“凄い事”をやろうとしなくてもいいのです。 マーケティングのドリルの穴理論のように、コラボレーション先が求めている結果が達成できるのならば どのような方法でも良いのです。 SRE本の著者の一人であるNiall Murphy氏は以下のようなことを仰っておりました。※ これはまさに、な例ですね。コラボ相手・またSREを実践しているチームにとっても時間は非常に重要な リソースです。その貴重な時間を守るためにも、「どのような結果を求めているのか?」「こちらから提 案できる別の結果の形はあるのか?」など対話を密にすることによって最適な解を探っていきましょう。 どう感じました?

    SSHしてコマンドを叩き、本番環境デプロイするというフローを採用していた企業から「より良いデプロイフローを設計 し、実装してほしい」と頼まれた。 私は当初、k8sを用いたデプロイメントフローを構築しようとしていましたが一ヶ月は掛かる予定でした。しかし、設計を 2度やり直した結果、Ruby on Railsで用意したURLにアクセスするとデプロイコマンドが走るように作成することとな り、最終的な工数は設計:3日と実装:3時間でした。 ※ Niall Murphy (2023年) SRE in the Real World - https://blog.relyabilit.ie/sre-in-the-real-world/ より引用