Direct URL:

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.

Direct URL:

At Uber, we have built the Odin platform for stateful workloads. We run more than one million containers on more than 70K hosts across multiple cloud providers and on-prem. This talk will cover how our graph database Grail enables both operators and automation to be effective at planet scale.
The primary take aways from this session will be about software architecture and the power of real time insights into your systems.

Direct URL:

DORA metrics (4keys) を導入し活用していくには、乗り越えるべき障壁が多く存在します。このセクションでは、ノバセル株式会社における 4key の導入のきっかけから計測基盤の構築・活用に至るまでを振り返り、どのような課題がありどう乗り越えたのかについて紹介します。

4keys 導入の各フェーズに合わせて、三つのセクションに分けて紹介します。

1. 4keys の導入フェーズにおける課題
2. 4keys の計測システムの構築フェーズにおける課題
3. 4keys の活用フェーズにおける課題

各セクションにおいて、我々が実際に直面した課題について掘り下げつつ、視聴者のみなさんにとって共感しうるポイントを織り混ぜてお話しします。  

Direct URL:

昨年のDevOpsDays Tokyo 2022で、私達は「ファクトから始めるカイゼンアプローチ ～「LeanとDevOpsの科学」を実践して～」という発表をさせて頂きました。今回は、Four Keysの計測事例を含めたその後の発表となります。

我々は、Four keysの計測によって開発組織のパフォーマンスを可視化しました。そこに加え、開発組織のあらゆる材料を可視化し、状況把握や課題発見を助け、事業の成長とプロダクト開発の相関関係を見出すためプロダクトアウトカムを定量的に計測するステップに進んでいます。

具体的には、アウトカム定量化の手がかりとしてEvidenced Based Management（EBM）が有効だと考えました。EBMでは、ビジネス価値を高めるために4つの重要価値領域に該当する指標を定め、プロダクトゴール達成のための実験のループを回すことを提唱しています。

EBMの重要価値領域とは以下の4つで、これらの領域は相互に影響を及ぼしています。

• 現在の価値（CV）
• 未実現の価値（UV）
• 市場に出すまでの時間（T2M）
• イノベーションの能力（A2I）

上図は「エビデンスベースドマネジメントガイド（日本語翻訳版）」より引用
https://www.servantworks.co.jp/resources/evidence-based-management-guide-japanese/

また、現在の価値(CV)と未実現の価値(UV)を定量的に可視化することで、真のプロダクトの価値が見えると言われています。

そのため、プロダクトマネージャー・ビジネス企画などプロダクトの価値について深く考えているメンバーにヒアリングを実施し、定量化できる要素を洗い出しました。

上記を踏まえ、本セッションでは、EBMを活用したアウトカム指標の可視化に関する取り組みについて発表したいと考えています。

Direct URL:

Like testing is an essential part of the software development lifecycle, automation is a non-negligible part of testing. Nowadays, most of us are somehow involved in automation, since it helps us to perform continuous testing and minimizes manual effort. It is great but also has several difficulties. Let's discuss how we can achieve coping with test automation challenges by going over real-life experiences.

What to expect from this session

As most of the QA people are doing test automation and there are several issues commonly faced by them, we will talk about proposals to cope with those test automation challenges. We will discuss ways to avoid broken tests after updated page layouts on the web apps that we are testing, to minimize the number of flaky tests, to automate scenarios where there is a hardware dependency, and to make implementation easier.

Common problems:

One of my recent projects was a warehouse automation system in which there are autonomous mobile robots moving around. I was supposed to test a scenario in which there is an obstacle in front of the robot, so it should find a new path and pass around the obstacle. How did I automate this test scenario? We will discuss several proposals for this and some other problems.

Some of the greatest common difficulties are:

• Coping with updates/changes
• Hardware in the SUT
• Implementation and Maintenance
• Time-consuming executions
• Reproduction of the issues found during executions

Fundamental solutions:

• Locators/Selectors improvement: Usage of test data IDs
• Simulation and test harness
• Non-functional testing
• Execution duration analysis and parallelization
• Logging and saving pieces of evidence in the pipelines

Direct URL:

このセッションでは、組織のサイロを打破してエンジニアが幸せにコラボレーションするための考え方である "インナーソース" について紹介します。

サイロ化した組織においてはコラボレーションが困難となり車輪の再発明が繰り返されることになってしまいます。そんな組織ではソースコードの共有やオーナーシップ確立が不十分であるため、コードの管理やメンテナンスに関する情報が不透明になっていることでしょう。

これらの課題に対処するため、アメリカやヨーロッパの大手企業が2015年から取り組み始めた活動が インナーソース です。この取り組みは、オープンソースのコラボレーションモデルを企業内に導入することで、エンジニアたちが風通しの良い環境で働けるようにし、エンジニア文化や組織の改善を促すものです。

インナーソースが実践されているのは Microsoft や Adobe などの Tech企業だけにとどまらず、ボッシュやシーメンス、鉄道や通信大手の企業がどんどん採用しています。このセッションでは、 インナーソース の考え方や、基本的なロール・プラクティスに触れつつ、 インナーソース戦略の各社の採用状況や事例についてご紹介します。

Direct URL:

This talk is designed for developers of all levels who are new to the Kubernetes ecosystem, or who want to better understand how to solve various security concerns when developing applications in Kubernetes. It covers the key security issues they may face and provides practical tips and best practices for addressing these challenges using open-source tools. Nic will take a real-life example of an application developed for Kubernetes and take you through missteps made along the way and how they can be easily solved. In particular, he will cover the areas of application configuration and deployment, sensitive information management, access control, policy-as-code, SBOM and more. It can be difficult to navigate the rich Kubernetes ecosystem as a developer. Hopefully, by the end of this talk, you'll have a practical example to remember and a good overview of the ecosystem.

Direct URL:

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マインドに転換していった軌跡を時系列でたどっていきます。

Direct URL:

DevOps efforts usually start with a technical need that is closest to the surface. However, there may be other underlying needs that are not articulated by the request owners. As DevOps practitioners, we can integrate subtle yet effective interviewing techniques into our 1:1s and meetings to collect these deeper, hidden needs.

Direct URL:

DevOps, SREの取り組みの中で「オブザーバビリティ（observability, 可観測性）」の注目が高まっています。

このセッションでは、オブザーバビリティとは何か、従来のプラクティスと異なる点はどこか、どのように始めることができるか、そして「未知の未知」にどう立ち向かうかについて、様々な書籍や私の活動の中から紹介していきます。

Direct URL:

Due to a last-minute cancellation, we'll be showing this excellent keynote by Kris, the co-founders of the DevOps Days.

13 years ago we had the idea to organise a conference in Gent to bridge the gap between developers and the people runing their code. It was the start of a new global movement. We never predicted that #devops would be where #devops is today. The word devops has evolved, the community has evolved.

Docker has solved all of our problems, the ones left behind were solved by Kubernetes. Everybody and their neighbour is Scrum certified now and we are all happily sipping cocktails on the beach. Or not? Why after almost 10 years of pushing culture change, teaching about Infrastructure as Code, teaching about Monitoring and Metrics … and help people to share both their pain and their learnings are most organisations still struggling with software delivery.

Over the years the word devops lost it’s meaning at least it’s original meaning. The real challenge for the next decade will be to see how we can revive those original values and ideas, if at all... Can we fix Devops ? This talk will give you some Ideas about that.

Direct URL:

Direct URL:

DevOpsを推進するにあたっては、ツール導入や自動化が注目されがちですが、組織内での「カルチャー」も重要な要素です。高いパフォーマンスを発揮するチームの土台づくりには、組織のサイロ化、マインドセットの違い、責任の押し付け合いなど…様々な問題が立ちはだかります。カルチャーの面でDevOpsを組織に浸透させていくのに、まだまだお悩みの方も多いのではないでしょうか。

本セッションでは、アサヒビジネスソリューションズ株式会社の技監である上條 真史氏をお招きし、カルチャー醸成やマインドセットの変革に重きを置く氏にパネルディスカッション形式でお話をうかがいます。同社は、アジャイル開発へシフトし、開発や運用を効率的に進めるためにDevOpsの概念を取り入れることにしました。まずはDevOpsを正しく理解するために、カルチャーや開発プロセスの基礎を学びました。そして、相互理解を深める研修を通して、縦割り組織であったことを実感し、他部門との連携の重要性を感じたと言います。

パネルディスカッションでは、アサヒビジネスソリューションズ株式会社が抱えていた課題や、それに対してとったアクション、社内促進のための取り組みや導入した研修などについてお話しいただきます。また、現在感じているカルチャー醸成の手応えや今後の展望についてもお伺いします。

DevOps推進におけるカルチャー醸成の重要性や具体的な事例を知ることができるセッションです。ぜひご参加ください。

【「フェニックスプロジェクト DevOpsシミュレーション研修」とは】
DX推進におけるカギとなる「DevOps」をゲーミフィケーションで体感できる、シミュレーション型研修。受講者は様々な問題を抱えた架空の企業の一員となり、続々と発生する問題に対処しながら業務を遂行し、どのようにDevOpsを実務環境に適用するかを実践的に学べます。
詳細：https://www.itpreneurs.co.jp/training/tpp/

【「DevOps-ABC」とは】
SB C&S株式会社とITプレナーズ社が共同開発したDX（デジタルトランスフォーメーション）に必要なカルチャーや開発プロセスの基礎などを疑似体験できる短期教育プログラムです。体験を通して、これからのビジネス成長に欠かせない「素早く開発し続ける」「ニーズに応え続ける」を持続するために必要な、モダナイズしていくための変革とは何かを発見することができます。
詳細：https://licensecounter.jp/vmware/lp/devops.html#devops-abc

Direct URL:

Direct URL:

In this talk, we will examine how your business can prevent breaches by eliminating secrets and adopting zero trust. We will examine the core pillars of an identity-native approach to infrastructure management and include real examples of how to implement these controls. 

Direct URL:

L'Oréal started its global Beauty Tech transformation more than 3 years ago, launching a massive program to make the group the first beauty tech company in the world.

In the Tech accelerators, multiple use cases powered by AI are being built to deliver some cutting-edge tooling to the employers but also the clients. The Time to Market that is expected is extremely low, so how do we deliver complex software, fast, without scarifying neither their stability, nor their security of business value.  

Let me walk you through this passioned journey that led us to build a highly automated & industrialized delivery ecosystem, that made our teams concentrate on what’s most important: creating value for the users.

All of these use cases are built cloud native, on GCP, how did we design our environment strategy? How do we train our AI models?

What are the technical stacks that we use?

How did we automate EVERYTHING, from repo creation, IAM set-up, infrastructure… to application deployment, audit and testing?

How central was Infrastructure as code (Terraform) was in this ecosystem? And how did we manage to implement a real “everything as code” and an “everything as a service” for all our organization

How did GCP empower or limit all of our DevOps/CICD ambitions? What are the roadblocks that we came across?

If you want to know more about this and, join this session to discover more exciting topics!

Direct URL:

Prometheus Remote Write is the protocol used to send Prometheus metrics from Prometheus (and friends) to compatible remote storage endpoints. Remote Write is generally used for long term storage, centralization, and cloud services. It also allows users to run Prometheus in an agent mode, reducing local storage requirements.

At Grafana Labs we host metrics storage for thousands of customers using Grafana Mimir. We also have a Mimir cluster that we run for ourselves as a central operations tool. We write all Prometheus metrics from our various production Kubernetes to this operations Mimir cluster, and we write roughly a gigabyte per second of compressed data over the network. This data is sent across regions and cloud providers to a central Mimir cluster. At our scale, this can become a substantial cost factor.

In this talk you will learn about the Prometheus Remote Write format and the Prometheus storage format. We will use the Remote Write format as an example of how structuring wire formats can reduce the required network egress bandwidth even when compression is already being used. More specifically, you’ll learn see how you can reuse concepts from database design, specifically Prometheus TSDB's index, to reduce the egress bytes by as much as 60%.

Direct URL:

Managing Infrastructure as code is one of the pillars on the road to full automation of apps&infrastructure. DevOps teams need to automate to highest level. I tell about how to do this using cloudnative tools such as Terraform, Kubernetes, and cloud native pipelines using Jenkins(), Tekton.

Direct URL: