Google内の組織であるDORA（DevOps Research and Assessment）では毎年「State of DevOps Report」という、世界各国での調査を元にしたDevOpsの組織への適用状況などの分析結果を公開しています。本セッションでは、2022年11月に公開された最新版のレポートをもとに、高パフォーマンスなIT技術組織がどのような技術をどのように適用しているのか、その分析結果を例を交えながら解説します。またセッション参加者の組織でレポートをいかに活かしていくか、その分析方法についてご紹介します。

I can provide the talk in English as I have given this talk at DevOpsTalks Plus Conference in Singapore as well.

The DevOps ハンドブックで示される3つの道、フローの原則、フィードバックの原則、そして継続的な学習と実験の原則。

ソフトウェア開発につきもののシステム障害。私達はそこから多くの事を学び、改善し、システムはより堅牢なものになっていきます。SREでもFour Keysでも、障害は発生しうるものとして扱われ、それをどのようにコントロールしていくかに主眼が置かれています。

その昔、私の現場では障害は「起こってはならないもの」として扱われていました。障害を発生させないことが目標として設定され、障害のような事象が起きているときにそれを障害として扱うべきか、という議論に時間が割かれることもありました。また、障害報告を上げると自分の責任になるのではないかという不安感から疑わしい事象を報告することについて心理的ハードルが存在していました。

2016年頃でしょうか。弊社がコミュニケーションツールとしてSlackを採用した頃から、その空気感は変わっていきました。#info_troubleという障害について報告されるチャンネルが開設され、「あってはならないもの」から「起こりうるもの」へと意識が変化していきました。

さらに時は流れ、「#info_troubleは障害について連絡する場だから、疑わしいレベルのものは投稿しづらい」という声があがるようになりました。そこで生まれたのが#info_trouble_lite。ちょっと挙動が変だよね、というレベルのものも共有されるようになり、「起こりうるもの」の規模が大きくなる前に対処できるようになってきました。

2021年。スクラムフェス大阪2021のセッション俺たちのDiRT - 継続的な訓練と振り返りで障害対応力をUPしように参加したメンバーがDiRTの実践を始めました。その取組は彼のチームの外側にも広がり、バックエンド開発チームを中心に実施されていきました。DiRTの結果をもとに障害発生時のオペレーションを改善したチームもあり、「起こりうるもの」は「起こる前に火を消すもの、起きたとしても素早く解決するもの」へと変わっていきました。

変更障害率0%よりも「継続的な学習と実験」を。10年前とはまるで違う価値観を有した組織へと転換していったのは、Slackのようなオープンコミュニケーションのツール、そのツールを中心に変化していった私達のマインドセット、外部からの学び、そして継続的な学習と実験が有用なものであるという実体験からくる気づきがあったからです。

このセッションでは、ある組織の価値観がDevOpsマインドに転換していった軌跡を時系列でたどっていきます。

みなさんはDevOpsDays Tokyoに来たぐらいですから、DevOpsに興味がある方たちだと思います。

CI/CDなど技術的プラクティスからDevOpsに興味を持たれた方、State of DevOps Reportや4 keysなどから興味を持たれた方、これから学びたい方、すでにある程度実践していて悩みを相談したい方、などなど、色んな興味があると思います。

そんなみなさんの興味を満たすために、DevOpsDays Tokyoで提供されるセッションを観ることももちろん有意義だと思います。

ただ、さらに学びを深めるためには、やはり、参加者同士の交流が必要ではないでしょうか？

せっかくDevOpsDays Tokyoに参加するぐらい熱量の高い方が集まっているのであれば、参加者同士懇親を深めてセッションについての感想戦をやったり、初学者に対するお勧めを聞いたり、自分の悩みを相談したりすることが出来たら楽しいのではないでしょうか。

とはいえ、少なくとも私は、知らない方に急に話しかけたり、話している輪の中に入ったりすることは、とても苦手です。

ネットワーキングパーティのような機会があったとしても、その時間を上手に使えずに話しかけられないことが多いです。

そこで、私のような人でも、知り合いを増やすことが出来るワークショップを行いたいと思います。

このワークショップは、Regional Scrum Gathering Tokyoで複数回開催して、毎回好評を頂いているものです。

このワークショップを通じて、知り合いが増え、より楽しむことが出来た、という感想を頂いています。

具体的な内容はOutlineに記載しますが、５～７人のグループに分かれて、『記者会見ワークショップ』を実施します。

このワークショップを通じて知り合いを増やすことで、より楽しいコミュニティ活動に繋がることを期待していています。

Ovsevavilityという言葉が浸透し始めてしばらく経ちますが、みなさんはどのように活用されていますか？本セッションでは、Ovsevavilityの3本柱であるログ、トレース、メトリクスという切り口だけでなく、監視対象レイヤーを次の6つにカテゴライズしてみます。

1. インフラ監視
2. APM
3. リアルユーザー監視
4. ログ管理
5. セキュリティ
6. ソフトウェアデリバリー

この中から、今回はAPM（アプリケーションパフォーマンスモニタリング）にフォーカスして、Observavilityの中でAPMが担う重要性について解説をしたいと思います。実際に、DatadogのようなObservavility Platformを使ったデモを交え、その有用性や活用方法を体感していただきます。
ログの中からどうやって必要な情報にアクセスするのか？数あるメトリクスは、なぜ運用監視のみならず開発でも役に立つのか？動的に変化するクラウドネイティブなアプリケーションの実行環境で何が起こっているのかをどのように効率よく見つけ出すのか？
本セッション終了後は、APMに対しての理解が深まり、みなさまのシステム運用・開発へのアプローチの見直し、改善につながれば嬉しいです。

Are you terraforming or click-opsing your data infrastructure? From spinning up virtual machines to managing application infrastructure across cloud regions, infrastructure-as-code tools have been widely used and adopted. Are you treating your data infrastructure in a similar way or still using complex scripts to create and manage your data infrastructure?

Terraform, an open-source infrastructure as code tool by HashiCorp, can be used to provision data infrastructure across multiple clouds. In this talk, I will discuss the need for an infrastructure-as-code approach for databases and streaming platforms. A large portion of the talk will consist of a demo that walks the audience through creating multiple data services using Terraform for a real use case. The demo will show the benefits of using such a tool over creating these services manually.

By attending the talk, the audience will understand the benefits of codifying the data infrastructure and walk away with the resources to be able to try Terraform out for their own data infrastructure.

本セッションでは、DevOpsのプラクティスに焦点を当てることで、DevOpsを現場で実践する障壁を下げるとともに、それぞれの現場のコンテキストで得たいアウトカムに応じたDevOpsのプラクティスを実践できるようになることを目指します。

具体的には、以下のような観点でDevOpsのプラクティスを深堀りしていく予定です。

• DevOpsのプラクティスにはどのようなものがあるのか？
• DevOpsのプラクティスで実践難度が低いプラクティスはどのようなものか？
• DevOpsのプラクティスで実践難度が高いプラクティスはどのようなものか？
• DevOpsのプラクティスを実践するとどのような恩恵が得られるのか？
• DevOpsのプラクティスを実践するとどのような副作用が発生し得るのか？

なお、セッションで紹介するプラクティスには、自分自身が現場で実戦経験のあるプラクティスも多くありますが、今回のセッションでは自身の経験に基づいた回答ではなく、320本程度の論文/書籍の内容に基づいた知見を紹介しようと考えています。