20200725 July Tech Festa 2020 memo

Qrunchからの移行（ログ）

2020/7/25 July Tech Festa 2020

B1:組織/企業/グループを超えたエンジニアのつながりを広げるイベントをしている話

  • 資料
  • NTT-G でのイベント開催実施経緯やその課題、対応策などを説明
  • イベント開催での工夫や苦労が分かる内容

C1：テクニカルサポートエンジニアという働き方 - 技術と英語で立ち向かうOSSとエンタープライズの世界

  • 資料
  • ひよこ大佐さん
  • SES 時代との差異をご説明。Twitter転職
  • 転職してもスキルはいかせられる
    • 知的好奇心
  • テクニカルサポートとしての必要なスキルが整理されている→　エンジニアとしての総合力が必要
    • 技術力
    • コミュニケーション力
    • メンタル
    • 英語力
  • トラブルシューティングのTips説明あり

G1:伝統的なエンプラ企業で取り組むインフラの設計書のモダナイゼーション

  • 資料★★★
  • 発表者
  • エンプラ系向けの説明
    • この領域の人にわかりやすい話（ウォータフォール型）
  • 設計書のモダナイゼーション
    • 高頻度の変更に耐えられるようにしたい
      • 従来は年単位の変更であった
    • オンボーディングのし易さ
      • 秘伝のたれ化の撲滅
  • 既存の開発は、請負契約をしたくなる（瑕疵担保責任から）
    • システム設計と契約書が同期していた（あしの長い案件なら問題ないが。。）
    • 意思決定者が多い
  • アジャイルでは準委任
    • IPAも定義しているとのこと
    • DoCoMo もそうしている事例あり
  • 全ステークフォルダの合意を取るのは不可能
    • 小さく始めていく
    • 実績を作っていく、という方法がポイント（★）
  • 前半のまとめ
    • ここまでにたどり着くのが大変
  • 設計書に何が書かれるべきか
    • DesignDoc
    • OSSのProposal
      • OSSの開発が、「要件」にマッチしている
  • OSSのProposalをインフラの設計書に取り込んだ話です
    • 目的とは、なぜそのように決まったのかわかるようにしている。後から見る人のため
    • エンタ系の仕様書は無駄に肥大化する傾向
  • 仕様書はMDで
  • 働き方
    • スキルではなく素質
    • 何もわからない人同士で話しても無駄。実際に動かしてみるべき
    • スケジュールが詰まりすぎている
  • なんとなく呼ばれる会議は、出席しないほうがいい（特にリモート会議）
    • 無駄。内職しているだろう

B2:組織に良い開発文化を植え付ける「Software Engineering Coach」という役割 / Role as Software Engineering Coach for better development culture

  • 資料
  • 登壇者
    • 元メーカエンジニア
    • 電子辞書の開発、海外勤務
    • 開発の責任者だった
    • 技術で解決できると思った
  • 成功と失敗はどう違うのか
    • SW エンジニアコーチ
  • ソフトウェアエンジニアリングコーチ
    • アジャイルの先導
    • 知識ではなく、（技術、ノウハウを）どう扱うかが重要

A3:OpenWorkが考えるリモートワーク時代のオンボーディング

  • 資料
  • オンボーディング 3ポイント
    • オンライン前提
    • ドキュメントの充実
    • 社内活性化
  • チーム主体のオンボーディングもある
  • インフラチームに入った実例
    • よくある話であるが、整理されていて参考になる

C4:凡人エンジニアの生存戦略

F5:想定外をオープンにする

  • 資料
  • 振り返り共有の意義

G5:理解して拡げる分散システムの基礎知識

C6:続・人生１００年時代の学び方

  • 資料
  • なぜ学ぶのか
  • 10年後何をやっているか？
  • パラダイムシフトは起こっていることを把握できない
  • 脳には可塑性がある
    • 学びをやめると老害になっていく
    • しかし、前例があまりない
    • 年齢を言い訳にしない
  • 輪読会の意義
    • わかっていないことがわかる
  • 自分が見えていないものは「見えない」
    • 新しい見方を発見できるか、がポイント

D6:Kubernetesでやりたいことがまだたくさんある

感想等

  • 現状の世の中の課題感、不確実性、スキルアップの工夫などが多く話されていた
  • リモート開催のため、地方からの参加が可能

参考

20200721 Developers Summit 2020 Summer memo

Qrunchからの移行（ログ）

Developers Summit 2020 Summer 聴講メモ

C-1 Outcomes over Output: Productivityの高い組織への変革

  • 多賀谷 洋一[メルカリ／メルペイ]

メモ

  • Outcome(成果) に目を向ける
    • 利用者の行動を変える、価値を認めて使っている、KGIアップ
  • ２つの不確実性
    • 目的不確実性
    • 方法不確実性
  • 目的不確実性
    • 課題
      • WIP は価値がない！
    • 対応策
      • 頻度高くリリースをし検証する
      • 大枠の指標(KGI)からKPIを定義、計測
      • 計測ではA/Bテスト
  • 方法不確実性
    • 課題
      • 受動的な活動が多い（Outcome に直接つながらない活動）
    • 対応策
      • デリバリパフォーマンス指標がある
      • 組織に大路が指標の設定
      • 組織変革もポイント

感想

  • 今後の製品企画での参考になる

C-2 心理的安全ジャーニー ～Slackで安全を実装する5つの手法～

  • 片岡 俊行[ゆめみ]

メモ

  • 「心理的安全性」という言葉を使わずにすむようにしたい
  • 内容をしっかり理解しないといけない（提供されている資料をしっかりと読み込む）

感想等

  • 「心理的安全性」というワードを最近よく聞くが、安易に使うものではない、ということが分かるセッション

A-3 New RelicのOSSツールとKubernetesクラスターの可観測性

  • 田中 孝佳[New Relic]
  • アプリケーションが動いてこそのkubernetes運⽤
    • アプリケーション中⼼のオブザーバビリティも獲得しよう
  • kubernetesの運⽤はどこに注⽬すればよいのか
    • オブザーバビリティプラットフォームの利⽤
    • MELTに着⽬したメトリクスの取得
  • OSSをどのように活⽤できるか
    • より広く使われ、より安⼼して⾃分のアプリの近い部分に組み込める

C-4 週一でリリースし続けるための、フロントエンドにおける不確実性との戦い方

メモ

  • MVP って聞き心地の良い言葉（自分もよく使う）
  • 不確実性を削減させるための戦略
    • リカバリ可能な地点を設ける
    • 開発はすべてモブプロで
    • でもズレは発生するので、発散と収束のバランスを取る
  • 定期的なリリース
    • 計測（数値の可視化）

感想等

  • ここでも「不確実性」が出てきた

A-5 Amazon/AWSの安全で自動化されたContinuous Deploymentsへの道

  • 林 政利[アマゾン ウェブ サービス ジャパン]
  • デプロイメントパイプラインを信頼するためのアイデア
    • デプロイ
      • メトリクスの監視と自動ロールバック
      • Bake Time
      • パイプラインを停止するイベント
    • ソースコード管理
      • 独立したパイプラインを用意する
      • コードレビューの重要性
    • AWSのサービスで自動ロールバックを実現する例(CodeDeploy)
  • デプロイプロセスの段階的な改善

A-7 コロナ禍の企業変革とデジタル変革 ～内製エンジニア組織がビジネスを牽引する時代へ～

  • 小久保 岳人[Insight Edge]/猪子 徹[Insight Edge]

感想等

  • 内政エンジニアの実際が垣間見える
    • P20, P29 の図は企画等で流用したい
  • ここでも「不確実性」の語りあり
  • 「知見」の底上げのやり方が参考になる(P39-P41)

C-8 アジャイルチームの成長に伴い起きる変化について

A-9 プロダクト作りのトランスフォーメーション

  • 市谷 聡啓[レッドジャーニー]

メモ

  • 不確実性
    • 事実との分断
  • 逆境
    • 未来との分断
  • 断絶
    • 理解との分断
  • ３つの分断でのプロダクト開発での１３の問題

感想等

  • 市谷さんの資料は参考になる情報量がいつもながら豊富
  • リモートワークでの「情報密度を高める」はその通り
  • 「価値観の分断」
    • Social Change! (P65)

全体を振り返って

  • リモート開催は、参加しやすい（リアルタイム参加しなくても後追いができる）
  • キーワード
  • 「不確実性」なか、業務を進めていくことに関して考えさせられる情報を多く得られた

20200702-03 HashiTalks: Japan メモ

Qrunchからの移行（ログ）

HashiTalks: Japan

聴講メモ (7/2)

俺のKubernetes Workflow with HashiStack

  • MS でAzure をご担当されている方
  • k8s でのTerraform 利点
  • リソースは様々
    • ライフサイクルが違う
    • 担当者の役割が違う
  • クラスタ上のリソースが誰よりなのか、と言う図(P14)が分かりやすい
    • App寄り：Depolyment, Ingress, Secret, ConfigMap,,
    • Terraform の守備範囲は、Appよりを含まない下位層
  • で、App寄りは
    • Flux + Helm Operator
  • サービスメッシュの必要が高まっている思う、と
    • そこで、Consul
    • Prometheus などの可観測性の統合が難しい
  • (感想)
    • Terraform とk8s マニフェストをどのように使い分けるべきか、と思っていたが、参考になる話であった

Cloud MonitoringとTerraformの付き合い方

  • 監視ツールもTerraform で管理している
    • 雛形をGUIで作成し、Terraformer でコード化

聴講メモ (7/3)

楽天における Terraform によるプロビジョニング自動化と便利なツール群

  • 楽天では、オンプレIaaS でサーバープロビジョニングにTerraformを使用

TerraformへKubernetesの哲学を輸入してみた

  • Speee のSRE の方
  • Terraform とk8s はよく似ている
    • 宣言的
    • 拡張性の高さ
  • k8s の方が一歩進んでいる
    • Reconciliation Loop
    • GitOps

Vagarnt と Terraform 私の利用法

HondaにおけるTerraform Enterpriseを用いたAWSマルチアカウント管理

  • インフラ管理者の登壇
  • 当初：自由にAWSアカウントをそれぞれの部門で取得
    • セキュリティ問題
    • 支払いの不確実さ
  • 打ち手：AWS Organizations
    • IT部門で主導：マルチアカウント管理を実現
    • ベルトプラクティスでアカウントを分離
    • 請求書の統合
    • 監査ログの集約
    • セキュリティポリシの強制
  • クラウドニーズ高まる（2018以降）
    • IT部門の運用・管理の限界：作業が手順書・GUIベース　→　Terraform
    • CFn は洗濯しなかった。今後AWS以外も使う可能性があるため
    • Terraform Enterprise 版を使うことにした

HashiTalks: Japan AMA with Mitchell Hashimoto

  • 日本について
  • リモートワークについて
    • 2002年の創業時からリモートワークを行っている
    • チャレンジはコミュニケーション
      • TZ のずれあるので
      • 文字でどう伝えるか重要　→　練習あるのみ
    • 社員のチャレンジは？
      • ツールは：
        • slack　ウォータクーラ
        • Googleメール
        • Zoom
        • Google Docs をヘビーに使っている
      • 90% はリモートワーク
      • TZ / ワークスタイルが違うので、ツールをうまく活用している
  • HiashiCorp 製品について
    • ユニークな名前
      • 命名にプロセスはない
      • ツールのメタファになっているか
      • Terraform 惑星を開拓、と言うところから
      • 言葉で響きがいいか、印象がいいかもポイント。他に同じ名前の製品が無いか
      • Terraformは、実はConstellationと言う名前になる予定だった
    • 新しいプロダクトについて
      • HPC ビジョン。発展していく。開発中
      • 社内で使っていたものをOSS化。Vaultがいい例
    • サービスメッシュがどう発展するのか
      • クラウドファーストでどうセキュリティを解決するのか、AP増大をどう解決するのかに必要な技術
      • B/G デプロイ、いかに素早く、出来上がった順番にデプロイできるかが重要
      • まだ、サービスメッシュは複雑な仕組み。まだまだ改善が必要
    • Terraform
  • 最後に
    • 今年は日本に行けない

その他

  • Ask Me Anything でMitchell Hashimoto さんがビデオ出演
    • 相変わらず、好印象
  • シンプルで使いやすいツールを次々に提供できる、HashiCorpの魅力あふれるイベントであった

Open Policy Agent とは

Qrunchからの移行（ログ）

Open Policy Agent とは

Open Policy Agent は、Kubernetes専用ツールではないが、以降はKubernetesで利用することを前提に説明を行う。

Policy as Code

その組織でのルールをコードで管理できるようにすること。Policy 定義からKubernetesマニフェストの定義チェックを行う。

IaC では、形式知をコード化してきた。 Policy as Code では「暗黙知」をコード化する、と言うイメージ

クラウドネイティブなチームを目指すには、必要不可欠。

なお、Policy as Code で検索を行うと、HashiCorp のSentinel が多く表示される。

Policy as Code with Terraform and Sentinel説明

  • (YouTube)
  • ポリシーとは
    • やってはいけないことや、定義しておかなければいけないことなどをチェックする構文
    • 本番環境は、こう言うインスタンスでなければいけない
    • 組織のルール（稼働時間とか）
  • ワークフローをIaC(Terraform)化
    • 人手でのワークフローから宣言的モデルに移ってきている
    • コードはレビューが必要になる　→　その解決策としてPolicy as Code
    • インシデント発生後の振り返りで新しいルールが発生する　→　これをCode化する必要がある
  • DevSecOps
  • Terraform向けPolicy

Open Policy Agent でKubernetesの何をチェックするのか

  • マニフェストをCI/CDプロセス内でチェックする
    • 社内ルール違反の有無をチェックする
    • Production Ready なリソース状態とする
    • セキュリティに配慮したリソース状態とする
  • マニフェストの構文チェック・ケアレスミスチェックをするツールは別にあるので、そのレベルのチェックは実施しない
    • Kubeval

使い方

conftest

Gatekeeper

The Rego Playground

Rule

package httpapi.authz

# 社員情報をインポート
import data.subordinates as subord

default allow = false

# 社員は自身の給与を参照できる
allow {
  some username
  input.method == "GET"
  input.path = ["finance", "salary", username]
  input.user == username
}

# マネージャーは部下の給与も参照できる
allow {
  some username
  input.method == "GET"
  input.path = ["finance", "salary", username]
  subord[input.user][_] == username
}

DATA

{
  "alice": ["bob"],
  "bob": [],
  "charlie": ["david"],
  "david": []
}

INPUT例1

{
    "method": "GET",
    "path": ["finance", "salary", "alice"],
    "user": "alice"
}

INPUT例2

{
    "method": "GET",
    "path": ["finance", "salary", "bob"],
    "user": "alice"
}

True にならない。。

links

20200701 Serverless Meetup メモ

Qrunchからの移行（ログ）

Serverless Meetup Japan Virtual #1

セッション

僕らがJeffyをつくった理由

  • Serverless Application Framework
  • メジャーなフレームワークは
    • 所詮デプロイツール
    • アプリケーションフレームワークはない、だから作った
  • Ruby on Rails を意識している
    • RailsほどFull stack Framework は要らない
    • 気持ちよく理想的なServerless Application を作りたい
  • X-Ray にデータを投げられるようにしたい
    • トレーシングが課題となってくると思っている

Provisioned Concurrency Dive Deep & Practice

  • まずはProvisioned Concurrency を利用しなくても通常のLambda フルマネージドでやってみる
  • 暖機が必要なケースはよく検討する

感想

  • Serverless にもアプリケーション開発に注力したいと言う流れがあると言うことが分かった

20200616 Infra Study Meetup #3「SREのこれまでとこれから」メモ

Qrunchからの移行（ログ） SRE

基本情報

SREの文化と組織」

  • 資料
  • マカレルのSREさん
  • 「システム」
    • 機械的なシステム
    • 人のシステム（運用チーム、開発チーム、、）
  • 自動車の安全性ができたように、システムもそのようになってきた
  • CRE
    • ユーザとの信頼関係
  • SLO Docsを作成し、SLIを決めていく（参考例がある）
  • SLIを実装し、SLOを現場から提示する（最初はこっちが楽）
  • 開発チームに所属するSRE
    • プロダクトに近いSLO/SLI が設定できる
  • 「全て問題ないことを示せ！」と言われる
    • とことんやると当然お金がかかる
    • 結局はお客様との信頼関係じゃないのか

LT

LT1「Incident Response」

  • 資料
  • メルペイSRE
  • インシデントへの心構えとか、共感できる内容

LT2「AIスタートアップにおけるSRE」

  • スタートアップ企業でのSRE事例
  • GitOpsを非エンジニアでも使えるようにしている

Sponsor LT2「契約書レビュー支援システムLegalForceにおけるマイクロサービス開発」

  • APIをR&D Zoo と称して、マイクロサービス 提供

LT3「Production Readyと開発プロセス改善」

  • 資料
  • 早期エンゲージメントモデル
    • 早い段階から開発のライフサイクルに関わる

20200613 KubeFest Tokyo 2020 メモ

Qrunchからの移行（ログ） Kubernetes

KubeFest Tokyo 2020

セッションより

10:30 - Open Policy Agent を使ってベスト・プラクティスをコード化しよう

  • 資料
  • KaaS の方(サイバーエージェント)
  • ナレッジ as Code
    • インフラのIaCはほぼ完成の領域。。
    • 知識をコード化していくべき
    • Knowledge as Code (まだ一般邸では無い)
    • Best Practice as Code (ゴロが悪い)
    • ベストプラクティスのコード化
      • クラウドネイティブなチームでは欠かせない
      • スケーラブルで回復性のあるチーム
      • メンバ間はいい意味で疎結合(新しい人が入る、出ていく人がいる、動くが早い)
    • 継続していくこと、できるところから初めて行く
      • 身近なものから -> k8s
      • マニフェストが手元にあるはず -> ベストプラクティスへ
      • 本番運用に耐えるように、、セキュリティ、、
      • ルールをコード化したい
  • Open Policy Agent
    • マニフェストをルールでチェックする
    • Rego でルール化できる！
    • Admission Controller で組み込む
    • ルールはConfigMap に書く
    • 現在は、Gatekeeper を使う方法をオススメ
      • ポリシーをテンプレート化できる
      • CRD で管理されるようになる
  • GitOps/Conftest/Gatekeeper
  • 利用者に対してRego 使えるようにしたい
    • マニフェストのベストプラクティスを集めて、広げていきたい
    • Rego でナレッジをコード化したい

感想、他

11:20 - Kubernetesトラブル原因特定容易化に向けたロギング強化機能

  • 富士通の方
  • k8s では４種類のログ
  • コンポーネントログは、次の段階
  • ロギングの課題
    • 複数のコンポーネントをまたがった確認が必要
    • Desired にしたがって動くことがログの紐付けが難しくなっている
  • 課題に対して、リクエストIDと言う仕組みを組み込もうとしている
    • コミュニティでの開発状況は、Provisional(設計段階)

感想、他

12:10 - 監視の基礎から知る、ヤフーの大量クラスタ監視システムの仕組み

  • ヤフーのKaaS
  • クラスタは日々増加
    • 2020/5 680+クラスタ
    • チーム：210
    • node：13,000
    • Pod：120,000
    • 運用チーム：20名くらい
  • 運用自動化
    • CIOps/GitOps
    • KaaS でインフラ構築の自動化
  • クラスタ監視
    • アプリの一部までKaaSチーム（SRE）で監視
    • Prometheus 利用(Blackbox_exporter)
    • 大量クラスタの監視
      • 集約システム化（Manager of Manager）
    • 集約データ
      • データ量が多くなるのでアラートメトリックスのみ収集

感想、他

12:55 - Kubernetes とオープンソース

  • サイボウズ
  • OSS の選定
    • 実績重視
  • OSS 開発のメリット
    • 品質よくなる
    • 過度な自社環境避けられる
    • 技術力のアピール
  • インフラのテストとアプリのテスト
    • 具体的な不具合の例
  • OSS推進室
    • 素晴らしく機能している（まさに推進室）

13:40 - 負荷を予測して事前スケーリングする HPA の Custom Controller 実装

  • サイバーエージェント
  • 資料
  • Horaizonatal Pod Autoscaler
    • 実測値をもとにスケールしていく
    • 負荷が上がらないとレプリカ数は増えない
    • 許容負荷ギリギリに設定すると間に合わない　→　余裕を持たせる　≒　リソースの無駄遣い
    • Cluster Autoscaler
  • 複数メトリックスの監視
    • 最大レプリカ数が選択される
  • IHPA
  • kubebuilder
  • Predictive HPA
    • 新しいのが出てきた

感想、他

  • こんな感じで、機能のオーバーライドができるのか

14:30 - Kubernetesクラスタのマルチテナンシーベストプラクティス

  • サイボウズ
  • 資料
  • 1,000大規模サーバにk8s 基盤構築
  • k8s 標準機能だけではマルチナンシーは不十分
    • Working-G ができている
  • ハードマルチテナンシは現状実現難しい
  • マルチクラスターの方がいいのではないか (KaaS/ヤフーさんの事例)
  • SSO でアカウント管理
    • k8s, kubectl, ArgoCD, Grafana
    • Teleport と言うツール利用
  • ネットワークポリシー
    • Calico
  • PSP
  • カスタムポリシー
  • 各コンポーネントの定期更新
  • アプリの開発効率化
    • 共通サービスをインフラチームが開発している
    • 開発者はCRDを使うだけでいい
    • モニタリング、ログ基盤の強化（まだまだ弱い）
  • 迅速なデプロイ

感想、他

15:35 - Open Policy AgentとSpinnakerで実現するマイクロサービスの安全な継続的デリバリー

  • メルペイ
  • 資料
  • CI
  • CD
    • Sponnaker でデプロイ
  • 課題
    • 自律的に開発サイクルを回したい
      • 記述としては間違っていないが、k8s マニフェストの設定の質がチェックできない（ルールにそぐわない）
      • デプロイの仕方がチームごとに異なる
      • サービス全体と、Devの進め方で相性が悪い
    • Spinneker Pipeline で設定ミス
  • ルール違反をチェックする仕組み
  • Spinnaker Managed Pipeline
    • Pipeline as Code / Devは何もする必要はない

感想、他

  • 安全なCI/CD の最新の事例を知ることができた

16:25 - Understanding CPU throttling in Kubernetes to improve application performance

  • 資料
  • Limit とthrottling　は違う
  • CPU Limits はいらないのではないか

感想、他

  • この資料でリソース配分の仕組みがよくわかる(はず)
    • 今後、何かあった際に参考する(Bookmark)

LT

[LT] GitOps環境におけるremote clusterでの開発

[LT] 手間をかけずにサービス監視する方法

[LT] EKS x locustで構築する大規模負荷試験環境

[LT] KubernetesにおけるCIについて

[LT] Kpt を使って組み換え可能な Manifest Pipeline を作ろう！

[LT] kubectl のプラグイン機構を活用してオペレーションを効率化しよう

[LT] Stargz Snapshotter: イメージのpullを省略してcontainerdでコンテナを高速に起動する

[LT] gVisorを活用して実現するこれからのコンテナセキュリティ

[LT] Re: Kubernetes-native テストベッドで始めるベストプラクティス模索

今回得られた知見

YouTube 公開後、聴講したものから

ヤフー/ゼットラボのステートフルアプリケーションへの挑戦

  • 資料
  • CaaS を開発し、Yahooが利用
    • マネージドKaaSを提供　２つのリージョンで可動
    • 利用者のk8s をk8s で管理。
    • クラスタ(VM)のスケーリングをOpenStack で実現
    • 独自のAddon-manager でGrafanaやPrometheus のアプリを提供
    • ステートフルへのチャレンジ中
  • Yahoo で利用
    • 広告配信システム
      • リクエストに応じて最適な広告を返却
      • 高速なレスポンスが要求される
      • Vespa(OSSの検索エンジン)
      • 24:30 監視システムへの設定変更の説明あり
    • 26:00 ごろシステム運用の説明あり

感想、他

  • ノードの作り直しを日々実施しできている（慌てない）
  • マシンリソースをうまく使い切れていないと言うとことをCaaS で解決

Resilience Engineering on Kubernetes ～ワンターレンの夜明け～

  • 資料
  • セルフヒーリング
    • 自身の回復機能はない
  • カオスエンジニアリング
    • 仮説を立てて、障害を起こす
    • 構造をしっかり理解した上で検証する必要がある
    • 守る対象から逃げない
  • STPA
    • ここが正常でも組み合わせで障害となることがある
  • Infrastructure as Data

感想、他

VMとAWS ECSがメインのインフラにKubernetesを導入した効能

  • サイバーエージェント
  • 既存との並行運用
    • 既存との共存
    • service mesh はコストがかかると判断
  • 開発環境と本番環境 の紹介
    • 11:45 ごろ
    • インフラ：Terraform
    • マニフェスト管理：Kustomize
    • CI：AWS CodeBuild
    • CD：ArgoCD
  • 受けられる恩恵 (16:56)
    • Devはインフラを意識することなく開発可能
    • CI/CDをほぼ自動化
    • 開発環境に何がデプロイされているのか分かるようになった
  • 問題
    • SRE チームで分担して担当した