こんにちは。ちゃんでらfeat.みです。
暑い日が続きますが、皆さん如何お過ごしですか。
さて、2022年7月8日(金)、新潟の名産の笹団子風のおやつを片手に「JaSST’22 Niigata」にオンライン参加をしてきました。
※「JaSST’22 Tohoku」「JaSST’22 Kansai 」も別の方が参加した際のレポートをブログ化としておりますので、興味のある方はそちらもぜひご確認下さい。
■「JaSST’22 Tohoku：テスト自動化その前に ～テスト自動化アンチパターン～」
■「JaSST’22 Kansai：テストオラクルのない世界」
テーマ「可観測性・Observability」
「Observability(オブザーバビリティ)」という単語をあまり聞き慣れない方も多いのではないでしょうか。
「Observability」は、日本語では「可観測性」となります。DevOpsの文脈で語られることが多く、運用・監視のPhaseでシステムを「観測」することで、継続的サービスに欠かせないものです。
私自身、開発の最終工程でテストをやるというようなプロジェクトにいた時には「運用・保守」のPhaseまで踏み込まないことが大半だったため、オブザーバビリティの概念をよく理解しているとは言えない状態での参加でした。
そんな参加者でも楽しめるように、オブザーバビリティは一体何なのかを基調講演で解説頂く所から本会が始まりました。
基調講演「オブザーバビリティと監視」
Autify取締役CTOの松浦 隼人様による基調講演では、「監視」と「オブザーバビリティ」の違いについての解説から、なぜ今オブザーバビリティが重要なのかについてお話されました。
監視とオブザービリティの違い
監視とは、システムとコンポーネントのふるまいや出力を観測し続けることで、メトリクス、アラート、ログが監視対象となります。過去の経験、傾向やプロダクトの傾向を基に監視のシステムを作っていきます。所謂「既知」の状況に重きを置いてきたものです。一方、オブザービリティはシステムの仕様や内部を把握し、「未知」へどう対処するかに重きを置くものといったお話がありました。
「監視」と「オブザーバビリティ」を「既知」と「未知」といったパラダイムの違いで表現されたのとは別に、「外側」と「内側」という言い方でも表現されていました。コンポーネントの数も増え技術がより複雑になると外からの監視は難しくなります。またシステムの使われ方も複雑化することで、一つの点に着目する監視の方法では不十分となり、また既知の状況から想定するやり方だとスピード感についていけなくなってきているそうです。とはいえ、オブザーバビリティよりも監視の方が向いている場合もあるため、オブザーバビリティと監視の特性を理解し、監視はオブザーバビリティを高める一つの手段でもあるという考え方でアプローチを考える必要がありそうです。
また、実際にオブザーバビリティを高める方法として、集計された現在の情報であるメトリクスと、イベント情報であるログ、どう辿ったかの情報であるトレースの3つの柱を挙げられていました。特に、ログについては、構造化(META情報の検討や何のログを出すと検索しやすいかの検討等)、高カーディナリティ、高ディメンショナリーをキーワードとした説明があり、具体的で参考になりました。(すぐに活用できそうです。)
ただ、松浦様もこれらはあくまで手段だと仰っていましたが、「未知の問題の解決に必要な情報は何か？」という観点でフィードバックと改善を繰り返して行くことが大事だと心得ました。
実際問題、QAが、プロダクトの設計段階からオブザービリティの重要性を説き、システムの内部を深く理解しつつそれを実行していくと考えると、QAエンジニアに求めるスキルはかなり広くなっているのだなと感じます。
※個人的に、アジャイル開発におけるアジャイルテスティングの延長上にもオブザーバビリティがあるのだと思います。
「今」を知ることに品質を良くするヒントがある
講演の中で一番心に残ったフレーズです。
エンドユーザやステークホルダにとってはリリース後のソフトウェアこそが「今」であるため、「今」を知らずに未来の開発活動やQA活動が良い形で進んでいくことはありません。
この観点は、開発に限らずすべてに通じる点だと身を引き締めました。
事例発表1「可観測性の先へ～人間系を含んだシステムのテストとしての障害訓練」
一つ目の事例発表はfreeeのただただし様による全社障害をキッカケにした障害訓練を行ったことから得た気づきの話でした。
過去に社内の全システムが停止する事態があり、それを教訓に年に1回、全社および部門単位で、セキュリティの障害訓練を行うことになったそうです。
※企画・運営のチームメンバー以外にはシークレットで実施したそうです！
実際やってみたところ、出た課題は、経営層と開発チームのコミュニケーション断絶、ハイブリッド出社によるコミュニケーションロス、正常性バイアスによる状況判断ミスといった課題…、人間が関わることでのネガティブな作用が浮き彫りになったようです。
弊社でも在宅勤務と出社のハイブリッドで業務を行っているため「あるある…」と思いながら聞いていました。
個と個のコミュニケーションでも、何も弊害がない状態ですら認識の齟齬やロスが発生するのはよくあることで、小さいチームや部門をまたぐとそれはより重大なロスに繋がるのは私だけではなくとも覚えがある方は多いのではないでしょうか。
人間系が一番脆弱
運用、監視のプロセスにおいては、ツール・システムの仕組みに人間のミスや無知を補う仕組みを導入しているのか、またそれは実行者の成長も見込んでいるか、というのをただ様はポイントとしてお話されていました。
セキュリティだけに限らず、社内で使うようなツールやシステムを検討する際には、
性善説や思いこみによる仕様決めになっていないかという観点で、定期的にフィードバックの収拾と状況のレビューをせねばと肝に銘じました。
事例発表2「そのプロダクト、「正常に動いてます！」と言えますか？QA視点からのObservability入門」
リンクアンドモチベーションの小島 直毅様による講演で、スイカの食べごろはオブザーバビリティなのか、をつかみに、オブザーバビリティはSREだけで作るのではなく、QAが監視を学び実施することでチーム全体でオブザーバビリティを実現していこうというお話でした。
講演からプロダクトが複雑化すれば組織も複雑化し、全体の認知負荷が高まるので、チームの中で新規技術に対するウェイトの低いQAが既存の「監視」を学びチーム全体での認知負荷を平均化するという風にうけとりました。
また、テストのオブザーバビリティとSREのオブザーバビリティは異なるもので、それをかけ合わせることでオブザーバブルなプロダクトを作れないかという点に着目してお話されていました。
オブザーバビリティはテスタビリティの要素の一つですが、例えば、オブザーバビリティはSREでは「可観測性」でQAでは「観測容易性」のように少し観点が違うと言われると理解できるような気がします。
講演の最後に、監視入門としてオブザーバビリティの事例紹介があり、具体的なシーンを想像しながら理解を深めることができました。※予稿集にも記載されていないので内容は伏せますが、役割の変化に着目して聴くことが出来ました。
個人的に、小島さんと言えばSigSQAのQMファンネルという印象があり、今回は少し触れたくらいかと思いますが、そちらと絡めたお話も是非聞いてみたいと思いました。
さいごに
テーマがテーマだけに、少し難しい内容なのかな・・と思って参加しましたが、初心者でも興味をもって聞けるような構成で、非常に楽しく参加することができました。
また今回JaSST初参加のメンバーからは、我々テストエンジニアからPOや開発者に働きかけをしながらオブザーバビリティの高いシステムがスタンダードになるようにしたいという非常に前向きな意見も出ました。
どの開発モデルでも、意外と盲点になりがちな運用・保守におけるオブザーバビリティへの理解が深まり、「JaSST’22 Niigata」の実行委員の方々に感謝です。
