DevOps Days Tokyo 2019 DAY1 参加レポート

カンファレンス内容

DevOpsDays は世界中で開催されているカンファレンスです。
ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスします。
IT技術を駆使して変化に強いビジネスインフラを実現するスキルを身に着けるために、国内外の最先端の事例とプラクティスを結集します。
海外から第一人者を直接招き、ここでしか手に入らない最新情報をリアルタイムで入手出来ます。
最先端のテクノロジの活用法はもちろん、先進企業で必要とされてきた背景までも理解し、正しく組織内に展開するための洗練された知見を得られます。

---

Report

Lessons Learned Since The Phonenix Project

Speaker: Gene Kim (Founder Tripwire)
Slide: https://www.slideshare.net/realgenekim/2019-top-lessons-learned-since-the-phoenix-project-was-released

技術的負債をまず返すこと。まず20%から改善活動を組み込んでいく

Memo:

• DevOpsとは
  • Better, Faster, Safer, Happier
  • 価値を届け続ける

1. リードタイム

   • 速く市場に出すことは、速く市場のレスポンスを得られる リードタイムだけ以上の価値が得られる
   • Code Deployemnt Lead Time の目標設定を行う Product Delivery (Build, Test, Deploy) 自動化するのが望ましい 速くミスに気付くことが大切
   • 正確にLead Timeをどう計測するか

2. コンウェイの法則

3. The Organization and The Architecture Of Our Software Must Be Congruent

   • 他のサービスに依存せずに自サービスをリリースできるか

4. リーダは必要

   • Vision ヴィジョンがあるか
   • Intellectual Stimulation チャレンジ
   • Personal Recognition
   • Supportive leadership
   • Inspirational communication

5. 価値は無償では得られない

   • 技術的負債を解消するには痛みを伴う
   • 技術的負債が増えると価値の提供スピードが日々遅くなっていく
   • 技術的負債が増え続ける
   • どうするか？まずFutureを止めて、負債を0にする。 そうなってからFurureに取り組む
   • 開発の20%の時間を技術的負債の解消にあてる。 日々の仕事を改善し続けること

• The Five Ideals
  1. Locality in our code and organizations
     1つのコードを見て変更をすることができるか
  2. Focus，flow and joy in our daily work
     学びを継続し続ける
     インフラはDeveloperが生産性を高めるようにするのが仕事
  3. Enablement of improvement and achievement
  4. A culture of psychological safety
  5. A ruthless and relentless focus on our customer

---

エンタープライズ企業におけるDevSecOps導入事例 （Intro to DevSecOps in Enterprise）

Speaker: Kyoko Yamada Associate Evangelist (DevOps) NTT COMWARE
Slide:

セキュリティ診断と改善をDevOpsサイクルに組み込む

Memo:

• DevSecOpsとは
  既に幻滅期

• セキュリティ診断
  静的解析、動的解析、ネットワーク脆弱性診断

  • ウォーターフォール型開発の場合 1発手動試験
  • DevOos型開発の場合 何度もやるので手動試験をやっていては回らない

• トイルの削減

  • devから導入
    • 開発チームが使えるように開発環境クラウドと開発環境を連携

• ふりかえり

  • 良かったこと
    
    1. 開発リスクを早期に検出し回避を実現
    2. 診断までの準備が短時間、自動試験によりスプリントを重ねるごとに効果大
    3. 開発者のセキュリティー意識向上、意識改革
  • 悪かったこと
    1. ツール導入後も手動診断が必要
    2. DASTはセキュリティ診断の知識が必要
    3. 過検知は余計な作業を増やす

• 今後
  ボトムアップ
  * DevaaS 2.0
  1. 動的検査にIASTツール
  2. ツールの導入障壁を軽減

  トップダウン
  1. セキュリティーチームが脆弱性診断状況を把握することによりガバナンスの強化とセキュリティポリシーの改善を図る

---

Service Operation Centered Development - サービス運用をまんなかにおいた開発

Speaker:Mitsuyuki Shiiba
Slide: https://speakerdeck.com/player/b4a9d6eb503d460db4efca2b109d66ba?feature=oembed

開発が運用を想い、運用が開発を想うことで良いサービスになっていく。
分かりやすくて、イメージが湧くセッションでした。
いいこと言いまくり。

Memo:

• こっち側とかあっち側とか線引きしない。どちらも同じサービスを開発している

• サービス運用をまんなかにおく
  サービスを育てることをやっている

• Development

  1. 全てのAlertに反応する → そうなると、Dev側でもアラートに対する関心が強まった
     • ログメッセージビルダを作った(原因と対応を書きログを吐かせる)
  2. Safe by Design
     1. fool ploof
     2. fail safe
     3. 冪等性
     4. Decoupled Architecture
     5. eventual consistency
  3. Services over Projects
     • 届けた価値を重視する
     • サービスに充てる時間は書くより読む方が圧倒的に多いので読みやすく書く

• Interaction

  • feel the forces
    他チームに敬意を払う
    その人に問題があるのではく、その人の周りに問題があると考える
  • see around the corner
    ビジネス、技術、デザイン、組織の変化を先読みして行動する

• 皆のその行動はサービスを良くする行動に繋がっていますか？

---

人事がDevOps研修を作っちゃった話?恐れ知らずのブルドーザー改革

Speaker: Ayana Yoshida, Kotaro Ogino
Slide: https://www.slideshare.net/ssuser845286/devops-140011849

何事も振り返りは大事。
人事の方のブルドーザー感が凄かった。

Memo:

• 人事が嫌いでムカついてメールを送った
  → MTGが設定された

• やってみてダメなら変える

  • 研修やってみて、アンケートとって、改善する

• 巻き込めそうな人を巻き込む

  • どの研修も"企画会議"を運営
  • 外部から講師を招きノウハウを取り込む

• 研修例

  1. ベストプラクティス
  2. ハンズオンは必須
  3. インタラクティブにする、交流しながらやる

• Fareless Change

• 振り返り

  1. 問題点の洗い出し
  2. 他の研修のいい例を提案
  3. 自部署でトライアル
  4. 振り返りMTG
  5. 改善点の洗い出し
  6. レクチャースタイル → ワークショップスタイルに変更

• 抵抗勢力より見方や仲間に目を向けるマインドセット

---

DevOps accelerates Digital Transformation - 組織でどのようにDevOpsを促進させるのか -

Speaker: Shingo Kitayama
Slide: https://speakerdeck.com/player/964f21fa47e04e0fab1e38de301465fc?feature=oembed

まず企業それぞれである指標の設定から。やみくもに改善しまくれば良いというものではない。
費用対効果の最大を狙う。

Memo:

• DevOpsを実践する企業は拡大しているが、ビジネス成果につながっている企業はまだ半数

  • 人材、組織、文化、プロセスをDevOpsに適合させていくことが重要

• DXは技術によって、人や企業文化プロセスを効率化すること

  • 費用対効果の最大化
    • 顧客の適切な品質とスピードを定義
      ↑DevOpsをやるときまず定義する

• リソース効率とフロー効率の順番を検討する

  1. 現状の運用状態を理解
  2. プロセスを改善
  3. コストを削減

• 2025年の崖

  • 既存システムのブラックボックス化を改善できない場合、技術的負債が増大しDXが実現できない
  • 課題
    • 自社経営陣の理解が得難い
      1. レガシーであることが自覚できていない
  • 対策
    • DXに対するビジョンと戦略を明確化

• デリバリーパフォーマンス(ITシステムが美自然巣に対してバリューをもたらす指標)

  1. リードタイムの削減
  2. デプロイ頻度の短縮
  3. MTTRの短縮
  4. 変更失敗率の低減

• ↑人/組織, 技術, プロセスの変革によって実現する

• DX

  1. ゴール設定
  2. 指標策定 Value Stream Mapping みたいなもの
  3. 施策
  4. 次のサイクルへ

• スピードを改善すると結果として品質が上がる

• まとめ

  1. 顧客の適切な品質とスピードを定義する 4つのKGIを定義し、優先度を定義する
  2. 文化やプロセスを効率化してコストを削減

---

DevOps with Database on AWS

データベースに対する変更をどのように扱うかは難しい問題です。
このセッションでは、ライフサイクルが異なるアプリケーションとデータベースに対する変更を適切に管理することを目的として、
代表的なデータベーススキーマ変更の手法を紹介し、それを CI/CD パイプラインに組み込む方法

Speaker: Atsushi Fukui, Yukitaka Ohmura
Slide:

アプリはユースケースごと大体CI/CDパイプラインがこなれてきた印象だがDBはまだまだこれからという印象。

1. DevOps with Databaseはなぜ難しいのか
   • 変更管理
     • アプリはgitなどがあるがDBは？

• モダンアプリケーションの特徴

  1. アプリケーションのライフサイクル全体に渡ってコンプライアンスとセキュリティを構築する
  2. アプリケーションの構造をマイクロサービスの集まりにする
  3. 可能な限りサーバレスの技術で構築する
  4. アプリケーションのモデリングとインフラにコードを利用する
  5. CI/CDを利用して高品質な機能を迅速にリリースする
  6. モニタリングによってアプリケーションの振る舞いの洞察を得る

• 変更をツールで管理

• オンラインでのスキーマ変更

  • MySQLにはオンラインDDLてのがある

• DB変更のブルーグリーンデプロイメント

• まとめ

  1. DevOps with Databaseは難しい
  2. アプリケーションのモダナイズによってDBの変更容易性が向上
  3. ？

Q1. DBのロールバック方法
1. オーロラはロールバックができるよ

---

DevOps導入支援、始めました

Speaker: Arata Fujimura Manager Classmethod, Inc
Slide: https://www.slideshare.net/slideshow/embed_code/key/MeUAeyi3oJoT5Q?feature=oembed

トークが面白すぎて全然メモが取れなかった。
あと公式からリンクされているSlidesが当日のものと違う・・・

Memo:

• なにはともあれリーンキャンバス

• 次なにはともあれインセプションデッキ

• 技術とプロセス

• AWS CI/CD構築ハンズオンを無料でやってくれる

• CI/CDパイプライン構築とアジャイル推進で分断されてしまった
  → 手段が目的化していた

• VSMして、課題解決して、VSMしてのループをまわす

DAY2 へ続く・・・