皆さん こんにちは 忙しい中集まって頂いてありがとうございます
私はNick Jainです
私はDynatrace APACの セールスエンジニアリングのディレクターです
今ここでとても素敵な トピックを差し上げたいと思います
まずは このトピックを 簡単に紹介したいです
これはインテリジェント可観測性と
自動パイプラインの Scale DevOpsとSREを用いた実践です
この議題は明確なアジェンダに 分かれていました
まず シーンを設定するために
マーケットのダイナミックス とそれに関連する顧客のチャレンジ
について説明したいです
次に チャレンジ軽減のために
Dynatraceの価値提案について詳しく説明します
その後 いくつかの テクニカルプルーフポイントを提供します
そのため お客様の使用する 大切なユースケース
について説明し
顧客の成功例を紹介した後
このプレゼンテーションに 締めくくりをつけ
リソースの方向性を お示します
さあ行きましょう
マーケットダイナミックスの観点から ４つのことがあります
一つ目はほぼ成熟のDevOpsです
これは 従来のことを考えると
ソフトウェアの開発 管理と配信に
多様な複雑性を持ちます
そのため 当然のように エンジニアは労力の削減と自動化の良い方法
を探していました
なので DevOpsがほぼ成熟するのも 珍しいことではありません
しかし その後 第二ダイナミックとキートレンドとして
我々はSREsが影響され成長していることを 観察しています
明らかに ブランド評判保護の責任があり
それと共に
収益ストリーム付随の プロダクションサービスに
高品質のSLAsを提供することで リスクが軽減されます
そして 三つ目はとても興味深く
自動化とAIOpsに 大量な重要投資
が行われています
そして 自動化とAIOpsは プロダクションだけでなく
プリプロダクションにも重要である ということを指摘する
ソートリーダーのことに関して少しお話します
四つ目の部分は
私個人でも かなりアップスキルするところです
つまり すべてはDevSecOpsに関しています
そのため BizOpsは 去年でとても有名なユースケースになりました
しかし今はDevSecOpsに 注目しています
これはセキュリティプラクティスを リアルタイムで導入するため
バルネラビリティが 連続的に検出される場合
手動的にコードスキャンする必要がありません
したがって これら新しいパターンの全ては
企業が 速くて安全な方法で
より優れたソフトウェアを構築できるよう
という基本目標を持っています
しかし いくつかのフェアとアンフェアのチャレンジが 常に存在します
これらは イノベーションの角度からのものです
スピードとスループット
そしてリスク管理とコラボレーションなどの ソフトウェアの側面もあります
次いで これらのチャレンジから 一つずつ取り上げて
少し深めに 理解しましょう
まず スピードチャレンジについて 見ていきましょう
これは手動と複雑なパイプラインが原因で リリースが遅らせます
その結果 締め切りに間に合わず
顧客の不満を招き
結局顧客の期待に応えませんでした
二つ目は DevOpsスループットです
ここでは 我々はアプリとDevOpsチームに もっとイノベーションして
DevOpsスループットを増加するように プレッシャーをかけています
さて 三つ目のチャレンジは リスク管理に関するものです
これは悪い品質のものや不安定なソフトウェア から出てきて
プロダクション環境に 入ります
これが起こるとカスケード障害と ドミ効果が発生すると
何回も何回も 言われています
それがたくさんの負の経験を及び データ損失
金銭損失 規制圧力
セキュリティ違反 そして何よりも
顧客の信頼度の低下に及ぼします
顧客のチャレンジには もっとソフトな一面があり
それがコラボレーションに関するものです
これは私の使命の一つです 私は自分が従業員だと思っていません
私は自分がDevOpsとSREの分野の 活動家だと思っています
今でも コンテスト不足な サイロチームがあることを聞き
そのチームたちに 自分のサイロデータがあります
そこではDevOpsとSRE目的で 一部だけのサービスが使われて
それがイノベーションを大幅に遅らせます
次にお見せしたいのは Dynatraceがこのようなチャレンジを
どのように支援できるかです
これは我々のバリュープロポのイントロで
まずスピードチャレンジに 取り組みましょう
これがDynatraceがアプリケーションの配信スピード 新機能のエンドツーエンドスピード
とタイムトゥマーケットを 75％イノベーションできるところです
第二に 全体的なスループットとボリュームに関して
DevOpsスループットを最低50％まで 向上させることをお助けできます
よりいい品質のリリースを 提供し
信頼を増やすため
我々はシDevOpsとSREの実践を用い シフトレフトとシフトライト
の両方に取り込んでいます
最後にこれらのサイロデータの 削除または解消に役立つという点では
我々は100％のコラボレーション を提供するだけでなく
100％優れたコラボレーションを 提供することによって
貴方方が今すでにやっていることと関連する 全てのリソースに使用できる
信頼すべく情報源を提供することを 保証します
繰り返しになりますが これらの機能は 戦略的価値を提供するために
今後は一緒になっていく見込みです
また お客様のビジネススピードに合わせて スケーリングするという顧客の期待に応えることができます
さて その前に ソリューションプレイの前に
技術的な証明ポイントを見てみましょう
どの部分が一番楽しみ にしてますか
ドグマやコアテネットを見てみましょう
成功するDevOpsの実践を構築するための
そして すでにそこに 到達している人たちのために
あるいは 少なくとも ある程度の成熟度に達している方は
この度は おめでとうございます
そして あなたに称賛と敬意を表します
なぜなら もしあなたが State of DevOpsのレポートに従うならば
重要な原則としては プラットフォームのアプローチをとることです
そして 本当の開発者達や オペレーターに
CIやCDなどのセルフサービスモデルと OPS管理 観察可能なパターンが
より良い判断をするために必要です
そして2つ目は
より良いマネジメントと管理のため テストと自動化を取り入れました
そして3つ目は 早期のセキュリティ統合ということです
伝統的に あなたが新しい機能を構築し
セキュリティ建築を提供することで
4日間から5日間 あるいは それ以上かかるかもしれません
手動でコードスキャンを実行するまで
私たちはそれを取り除き
自動化と継続的な脆弱性スキャンにより DevOpsプロセスに焼き付けたいと考えています
ガートナーも例外ではありません ガートナーとの間には いくつかの相乗効果が見られます
この分野のオピニオンリーダーです
そして 組織のDevOpsの成熟度や SREの導入状況に注目です
彼らもプラットフォームアプローチの利用 を推奨しています
コアテナントの一つとして
また 開発者やオペレーターは コアな活動に集中できるようになります
しかし 少しニュアンスを加えているところがありますので 彼らはAIOpsの使用を推奨しています
ここでは 生産現場での観測性を高めるために AIOpsを導入するのではなく
スケールアップしたアジャイル全体の エンドツーエンドを実現のためです
スクラムやカンバンを中心とした 開発手法の練習です
ところで私たちは設計図を理解しています
スケーラブルなDevOpsとSREの実践 を目指します
では なぜDynatraceが を作成する必要性を感じたのかを見てみましょう。
同社のクラウドオートメーション ソリューションテンプレートです
そして その中でも コアなユースケースは何か
今度 この特別なスライドでは ユースケースを紹介したいと思います
そして 私はあなたにもっと その見解を説明します
どうすれば 戦略的チームレベルを達成できるのか
または その能力を活用することによる 財務的価値期待できるかを説明します
だから まず最初に リリースの観測可能性に注目してみましょう
第二に 重要なコンセプトである サービスレベル目標
または 同じSLOs を使用する場合
伝統的に生産環境で 使用されています
さらに プリ－プロダクション でも活用できます
自動化に対応した品質ゲートを 設置することで活用できます
次はいよいよ クローズドループリメディエーション について説明します
インシデント管理ワークフローの中で 自己治癒力を発揮しています
そして最後に プログレッシブデリバリー それについて 早期導入者もいますが
プラットフォーム企業と
しかし 現在では 企業での採用が急速に進んでいます
皆さんの多くいる場所です
それでは 最初のユースケースとして リリースの観測性を見てみましょう
ここでの目的は リリースマネージャーが 自信を持ってリリースできるようにしたいのです
しかし 共通の課題があります ほとんどのリリースマネージャーは
複数の配信ツールを使い分けています
これらがJenkinsやGitLabになるわけですね
またはAzure DevOpsなどのツール
そして クラウドネイティブな空間では SpinnakerやTektonを使っているかもしれません
または fluxのようなものまで
さて この方法の問題点は
結局 あなたは 複数の真実のソースを作ることになります
すべての配信ツールは 独自のレポートを作成しています
例えば パイプラインがどのように 作動するかについて
パイプラインの健全性について
または どの環境で デプロイしているかを確認してください
しかし あなたは次のような 根本的な質問には答えられないのですね
何がどこで公開されるのか そして誰が
これは新しいものを発表に 良いタイミングなのでしょうか
これは意思決定をする上で 非常に重要なことです
ここで Dynatraceがリリースする インベントリツール
やダッシュボードが登場します
これでまず リアルタイムに在庫を把握することができます
コードパイプラインを持つ すべてのアプリケーションで
すべての異なる配信ツールです
DynatraceがOneAgentを使って これらの環境を観察している場合
アプリケーションのバージョンを 示すメタデータも収集しています
某ビジネスサービス名に対して
これらのコードパイプラインを 起動するための環境です
そして 既存の問題や 状態があるかどうか
本番環境で再現と となる可能性があります
リリースに向けて実行していく中で
お客様の印象より悪化する 可能性があります
またはユーザーエクスペリエンスの 観点からも考えられます
さて ここでの考え方は リリースマネージャーが答えてくれます
何がどこに配置されているか どのバージョンでいいのか
アプリケーションが どのような環境で動作するのか
ここで 私たちはあなたの バグトラッキングシステムにリンクすることができます
JIRAやGitHubのような 他にもたくさんのツールを開発しています
しかし あなたは 既存の生産問題を 注記することができます
そして 直接に文脈のリンク とそれらの問題を結びます
なので あなたが決められますよね。
リリースを防ぐために ユーザー体験はさらなる影響を与えます
そして 最後に あなたは下記のように答えるられます
特定の環境で 何が起こっているのか
リリースイベントストリームの観点から
また あなたは機能フラグの 効果を見ることができます
設定変更 新機能のロールアウト
そして何よりも カナリアデプロイ
つまり 要約すると 私たちが実際に提唱しているのは
自動配信機能と それに関連するリリースの追跡です
そのため コアの変更や
プルリクエストを行う際に パイプラインを起動させることができます
あなたは 現地で何が配置されているか を観察することができます
そして あなたは現地の問題に 統合することもできます
あなたのユーザー体験にも 影響を与えてくれます
より良い判断をするためです そして 最後に
AIコアエンジン Davis も
根本的な原因分析をあなたに 提供することが可能です
これらの 配信関連のメタデータを使用し
自動化されたRCAに取り入れています
これはDynatraceで提供されている 観察可能な重要なパターンとして注目されています
さて これで少し理解できたのでしょうか では 次の項目に移ります
現在最も絶賛されているコンセプトの一つである SLOの概念について 以下私の意見です
開発者とオペレーターの間の共通言語として
今まで SLOs を深く理解する時間 がなかった人は
序章について説明します
そして まず SLIです
SLIは単純な指標やグラフです
ビジネスのKPIを測定するために 使用されています
いわゆる ビジネスサービスのパフォーマンス または技術サービスのパフォーマンス
あなたのアプリケーションに ゴールデンシグナルを考えてみてください
2つ目は サービスレベルの目標です
合意された目標を達成するために
エンドユーザーに 最低限のサービスを提供します
そして その基礎となるシステムの動作について
可用性の観点から 劣化やエラーが発生することがあります
なぜなら アプリケーションに設定した 値や目標と関連あります
そして3つ目は
通常 商業契約などに 含まれるものは何でしょうか
それはSLA 部分ですね これは結果です
いい反発があるかもしれませんね
でも反発期間はよくないです
優れたサービスを提供することで 安価で受けることができます
または違約金が発生したり
最低限のサービスを提供できない 理由です
ぜひ AWS EC2サービスレベル同意項目 について 確認してみてください
SLAについての理解を 深めるためです
さて ここで開発者が受け入れている 4つのコンセプトがあります
そしてプロダクション エンジニア達 も かなり深く受け入れているようです
これが予算の誤差です
つまり ここでは 各SLOに競争力のある誤差のある予算を与えます
これは許容できる最大の ダウンタイムのことです
劣化やエラーは 本番環境で
特定のアプリケーションに対しています
ですので 最低限のサービスを 提供できるということですね
そして 誤差のある予算が消耗されと
誤差のある予算を再交渉することもできます。
機能がまだ リリースされていない場合は
本番環境に影響を与えないために 発売前に止めましょう
あなたの大切なエンドユーザーのためです
そこで もう一度強調しておきたいのですが
これらのことを行うのはとても重要です
Dynatraceの視点で見ると
ここで一つ良いニュースは 我々がSLOs ネイティブに扱えるようになったことです
そのため SLI SLO SLAを 美しいダッシュボードで
目の前のアニメーションに表示できます
そして 私たちは本当に ベスト プラクティス に従うことをお勧めします
そして 上位の SLOを始めてみましょう
これらはフロント関連や ユーザーエクスペリエンス関連 のものです。
そして これはあなたに次のような見解を与えるはずです リリースすべきか あるいは リリースできるのか
では SLOsがどのようなものか見てみましょう
SLOsはプレ－プロダクション環境でも応用されています
自動化された品質ゲートを導入されます
次のユースケースです これからご紹介していきたいと思います
SLOは DevOpsとSREの間の架け橋となります
では SLOってどうやるの
つまり よく考えてみると
DevOpsエンジニア達 はデリバリーの スピードを上げるために自動化を取り入れ
そして 展開頻度の観点から パフォーマンスを測定し
変更のためのリードタイムも必要です
そして今 考えてみると 違う側面から考えてみましょう 生産側では
自動化したり
観測性を取り入れたりして
回復力のあるオペレーションを 提供してくれるSREがいます
そして 彼らは故障率の変化や
特定のサービスを復旧させる までの時間を測定します
今 ほとんど このうっかりしたアンチパターンで 動いています
ですから SLOは まさにそれらを一つにまとめることができます
皆さんにお伝えしたいのは 私たちが本当に提唱しているのは
そのプロダクションSLO を 本番前の環境に導入し
より早い段階で行われます 新機能をエンドユーザーに提供するのに
必要な時間を最適化することができます
ですので SLOを使用して 質の高い作品かどうかを判断するのはいいですね
そして それに基づいて
あなたは自動的かつ迅速に フィードバックが可能になります
不良債権の処理もできます
戻した理由を開発者に フィードバックします
そして さらにビルドが増えてきます
同じプロセスを異なる環境で 実行した場合
その法案が製品化されるまで
ですので ERTの成功例を参考に していただければと思います。
クリスチャンは 私たちと密接な関係を築いています
私は DevOpsエンジニアとして ERTのモットーのように
あらゆる場面で自信を与えてくれます
私たちは確信を持って デリバリーパイプライン
ご覧の通り 私たちは異なる場面で SLOsの活用がありました
目の前のスクリーンをご覧ください
ここでのアイデアは 品質ゲート 基準チェックなど
品質が高いであるかどうかを 人間が検証するよりも効率的です
そこで このようなレポートを用意しました すべて重要なSLOsが記載されています
ヒートマップ形式で表示しています
それに伴い DevOpsエンジニアは
ビルドを促進するか ビルドを撤回するか を自動的に判断されます
さて 次は私たちが今後それを 一般的なものになることを信じてます
プログレッシブデリバリー
だから カナリア デプロイメントのブルーグリーンの デプロイメント または機能フラグを考えてください
そして ここで一つアイデアは プログレッシブデリバリー があなたのスピードアップするのを助けてくれます
収益パイプラインの構築に 失敗した場合のリスクを管理しながら
あなたのトップラインとボトムラインに
ここで 次のような答えが出てくるわけです
リリースするのに最適な時期はいつですか
発売された場合 どのような影響が考えられますか
現在 どのバージョンが導入されているのか また 何か障害があるのでしょうか
さらなる革新をもたらすことなく そのような環境にリリースされることになります
さて 私たちがここで答えたいのは
リリースしても しなくでも
この発音が好きです ちょっとしたリズム感がありますね
さて ここで能力を見てみましょう
まず 私たちはあなたが より良い決断をするために
最適なターゲット層を見極めることをサポートします
カナリアデプロイを試してみたいと思うような地理的条件
あるいは 目的がユーザーエクスペリエンス の向上であれば
これまで障害となっていた 生産環境
やユーザーエクスペリエンスの向上のために リリースすることができます
正しいデータを手に入れるため どのようなパフォーマンスが得られるのか
歴史上に作られたものです
そして最後に イノベーションの 革新を押し出すのに最適な時期を理解することです
それでは そろそろイベントを終了したいと思います
しかし もしあなたが 大胆で動きをするなら
あなたのリリースの宣伝方法で
本番でのテストを考えているかた
あなたはお客様が最も忙しい時間帯に リリースを促進することもできます
お客様がデジタルフロントエンド や店頭に到着するときに
あなたのサービスを利用し 実際に取引し
カスタマー旅を完了させます
つまり このアイデアは
あなたに新しいリリースの潜在的な 反発を理解してくれます
ここでは 新しいリリースを見て 前作との比較ができます
この新しいリリースでどれだけオーバーヘッド を増やしているのか
この新しいリリースでは エンドユーザーへの 反応が向上させますか
今回のリリースでデータベースに 影響はありますか
ここで データベースの総呼び出し回数が10.5倍 になっていることが分かります
このような大量のデータを扱うことができるかどうか
を判断することができます
最後になりましたが
ここで 191 秒のスローダウンをしたいですので ご理解ください
とてもパワフルな機能です
最後に 私は技術的な使用例を 紹介して
終わりにしたいと思います
ではここで 私はAIを使って
あなたのSLOs誤差予算を守りたいと思います
最も重要な通知チャネルに統合し
そして 立ち上がる時には オートレメディエーションと自己修復機能を備えています
オートリメディエーションや や自己修復がうまくいかない場合
特定の問題を回避さて 適切なオーディエンスへ行きます
PagerDuty ServiceNowを経由で xMattersなどの人気チャンネル
クライアントが一般的に使用されています
さて ここで 私は速やかに TIAAに検査してみたいと思います
TIAAは保険会社の大手です
そこで Dynatraceを使って スピードアップします
DevOps パイプライン
そして かなり多くの キーパーソンがいました。
しかし Dynatraceの影響に関しては 増加の傾向があります
本番前の環境問題を 早期発見するには時間が必要です
革新的な仕事をするために 何千何万時間を割くことができるのです
これこそが なぜ TIAAがより多くの特許を申請 することができた理由です
そして イノベーションのための時間を より多く確保することができます
AGIIも重要な学習事例ですね
COVIDを追跡するアプリケーションを使って COVIDと戦ってきました
そして 彼らはDynatrace クラウド 自動化ソリューションを使って同様のメリットを得られました
DevOps リード ペルソナで ERTのお話 とよく似ていますね
さて 早速ですが 要約したいと思います なぜDynatraceなのか
私たちは あなたの不安や ジレンマを解消するために
そして幸せなDevOpsとSREチームを作り
使うことができ 立ち上がることができる
自動化されたパイプライン そして可視化オブザーバビリティ
しかし その後 すべての重要な ユーザケースを使い
今回のプレゼンテーションで皆様と共有しました
そして もう一つの重要な部分は 膨大な数の参加者がいることです
専門的なサービスチームが あなたの旅をお手伝いします
ここで いくつかのリソースをご紹介したいと思いますので Dynatrace Universityをチェックしてみてください
またはYouTubeチャンネル にもアクセスできます
これらの美しいユースケースのすべてが 実際に動いています
ご清聴頂き誠にありがとうございました
質問応答コーナで また皆様と交流しましょう