変更障害率0%よりも「継続的な学習と実験」を価値とする〜障害を「起こってはならないもの」としていた組織がDirtの実施に至るまで〜

location_city Tokyo schedule Apr 18th 04:00 - 04:45 PM JST place Hall A people 33 Interested

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

 
 

Outline/Structure of the Talk

  • 障害とはあってはならないものである
    • この障害報告を作ったのは誰だ!
    • 目標: 障害件数0件
      • これは障害のうちに入らないとおもいます
    • なぜ復旧より原因究明を優先してしまうのか
  • 障害とはおこりうるものである
    • オープンコミュニケーションツールが変えるマインドセット
    • あれ?共有したほうが復旧まで早いんじゃない?
    • これは障害?障害じゃない?
    • 疑わしきも報告しよう
  • 障害とはおこりうるものであり、先回りして対処できるものである
    • スクラムフェス大阪の衝撃
    • そうだDiRTやろう
    • DiRTよさそうだから私達もやろう
    • 「障害はおこる」と認めたところから改善は始まる
  • まとめ

Learning Outcome

  • 継続的な学習と実験が組織に根付いていくプロセス
  • うまくいっていないことを共有できるマインドセットの作り方

Target Audience

システムの安定性に興味があるエンジニア,本番障害に抵抗があるエンジニア

schedule Submitted 3 months ago

  • Yoshi Yamaguchi
    keyboard_arrow_down

    Yoshi Yamaguchi - DevOps最新動向 高パフォーマンスな技術組織の秘訣

    20 Mins
    Talk
    Beginner

    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.

  • Yuki Hattori
    keyboard_arrow_down

    Yuki Hattori - 組織のサイロを打破する!エンジニアがオーナーシップを持って共創する開発プロセス「インナーソース」

    45 Mins
    Talk
    Intermediate

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

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

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

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

  • Kazunori Otani
    keyboard_arrow_down

    Kazunori Otani - モニタリングからオブザーバビリティへ

    45 Mins
    Talk
    Intermediate

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

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

  • Sugii Msakatsu
    keyboard_arrow_down

    Sugii Msakatsu / Yoshitomo Kanaji - 都庁でアジャイルを実践するための「都庁アジャイルプレイブック」のご紹介

    45 Mins
    Talk
    Intermediate

    東京都庁でのアジャイル推進の事例を紹介いたします。

     

    現在、東京都はDXに全力で取り組んでいます。

    業務改善・業務改革、より良い行政サービスを実現するためにアジャイル開発は不可欠なものと考え実践を重ねているところです。

    本セッションでは東京都デジタルサービス局が中心となりアジャイル開発の事例やパターンをまとめた「都庁アジャイルプレイブック」を紹介します。

    • 従来と異なる手法であるアジャイル開発の始めかた

    • 事業部門と開発チームとのコラボレーションの工夫

    • 進める中での課題・改善の事例

    などなど、公共分野ではない方々にも参考にしていただける内容です。

  • Cheshire Cat
    keyboard_arrow_down

    Cheshire Cat - 仕様について話そう、仕様について話すことについて話そう

    Cheshire Cat
    Cheshire Cat
    Software Engineer
    ProofCafe
    schedule 2 months ago
    Sold Out!
    45 Mins
    Talk
    Advanced

    本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を数学的記法により厳密に記述し解析する技術について紹介します。

    システムやプログラムの仕様を表現するにあたって、「安全性 (safety)」と「活性 (liveness)」の二種類の仕様があることは古くから経験的に知られていました。非形式的な表現で述べるなら、安全性とは「何か悪いことが決して起こらない性質」であり、活性とは「何か良いことがいつかは起こる性質」であるといえます。

    安全性と活性はそれぞれテストを行うために必要な操作が異なるため、与えられた仕様がこの両者のどちらなのか、あるいは混合しているなら分離して個別にテストすることが可能なのか、という問題が自然に生じます。この問題に対して、1985 年、Alpern と Schneider が位相空間論の言葉を用いた最初の定式化を与えて以来、さまざまな分析手法が用途に合わせて考案されています。

    本セッションでは上記のような関連研究を通して、システムの仕様はどうしたら厳密に表現できるのか、また仕様を検証するにあたってどのように数学的な理論を適用するべきなのか、という問題意識について解説し、実際にそれらの理論が効果を上げているツールや事例について述べたいと思います。

  • Shinya Ogasawara
    keyboard_arrow_down

    Shinya Ogasawara - せっかくだからDevOpsDays Tokyoに来た人と知り合いになるためのワークショップ

    100 Mins
    Workshop
    Beginner

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

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

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

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

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

     

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

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

     

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

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

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

     

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

     

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

  • Dewan Ahmed
    keyboard_arrow_down

    Dewan Ahmed - Do NOT click-ops your data infrastructure

    Dewan Ahmed
    Dewan Ahmed
    Senior Developer Advocate
    Aiven
    schedule 6 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    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.

  • Ryosuke Iwanaga
    keyboard_arrow_down

    Ryosuke Iwanaga - "あらゆるコミットを1時間以内に本番にデプロイ可能にする"と何が嬉しいのか - 継続的デリバリーの基礎

    20 Mins
    Talk
    Beginner

    David Farley の"Modern Software Engineering" によると、"あらゆるコミットを1時間以内に本番にデプロイ可能にする"を目標にすることで、効率的なソフトウェアエンジニアリングが可能になります。例えば、この目標のためにはテストを考えなければいけませんし、自動化も進めなければなりません。私が前に働いていたAmazon でもまさにこの理屈に従ってCI/CD パイプラインを活用していました。本セッションでは、"Modern Software Engineering" の考え方を元に、私のAmazon での経験を踏まえて、この目標がもたらす効能をまとめてみたいと思います。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - これならできるDevOps!〜320本の論文/書籍で探求するDevOpsのプラクティス〜

    20 Mins
    Talk
    Beginner

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

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

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

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

  • Kentaro Arakawa
    keyboard_arrow_down

    Kentaro Arakawa / Akihisa Kida - DevOpsで結ばれた2つの部署の物語:組織感コラボのハーモニー

    20 Mins
    Talk
    Beginner

    本セッションでは、組織間のコラボレーションがDevOps実践において不可欠であること具体的な事例交えながら紹介します。

    弊社でも、組織間のコラボレーションによるDevOps実践を開始しました。
    まずは定例会議で課題感の距離を詰め、ベイビーステップな施策を複数講じました。
    自動テストの推進やスクラムを始めDevOpsのプラクティスを次々に導入していった結果、2つの部署の出会いから約10ヶ月で開発プロセス改善やチームビルディングなど良い成果がみられるようになっています。

    このセッションでは、得られた知見や思いを実例を交えながら紹介し、参加者の方々が組織間のコラボレーションを促進し、DevOps実践を進めるためのヒントを得ることを目的としています。

    組織内でのコミュニケーションやコラボレーションに課題を抱えている方、またDevOps実践を進めたい方は、是非本セッションにご参加ください。

  • Ken Takayanagi
    keyboard_arrow_down

    Ken Takayanagi - DevOpsにおけるワークショップというアプローチ

    20 Mins
    Talk
    Intermediate

    「共創」にはワークショップでのアプローチが有効です。

    DevOpsを進める時によく語られる壁として「分断」があります。最近ではビジネスと開発も密接に繋がってきていることで、ビジネス、開発との分断状態もあります。

    その状況に対して、コンサルティングや、マネジメントなどさまざまなアプローチが行われてますが、今回はワークショップという「共創」のアプローチについてワーク内容や事例を交えて話します。

     

help