2019-07-08 Tech-on MeetUp#07「OpsとDevの蜜月な関係」 #TechOn東京
2019/07/08 に開催された 【増枠】Tech-on MeetUp#07「OpsとDevの蜜月な関係」のイベントレポートです。
●イベント概要
今回のコアテーマは「DevOps」
過去対立しがちであった「Dev（開発）」と「Ops（運用）」の関係が、お互い寄り添い、ビジネス貢献のために強調しあう、いわゆる「蜜月な関係」を目指して「DevOps」に取り組む企業も増えてきました。現在では「NoOps」や「SRE」など、Opsを主体とした様々な考え方が議論されています。
本MeetUpでは、「DevOps」の中でもより「Ops」にフォーカスを当て、Ops視点でのDevとの関わり方や、Opsの課題を技術やプロセスで解決する取り組みについて登壇者にお話いただきます。
現在Opsで悩まれている方はもちろん、Devの立場の方もこの機会をよりOpsに寄り添うキッカケとしてご活用いただけますと幸いです。
■Ops meets NoOps ～そのとき何が起こったか～
真壁 徹さん [日本マイクロソフト]
●自己紹介
・マイクロソフトでSA
・アプリも嗜むインフラ野郎
・Azureやってます
・最近はk8sやってます
本も出ました
・NoOpsコミュニティのサポーター
●NoOpsのインパクト
・1年くらい前にNoOps Japan Community発足
・pulickeyに取り上げてもらった
・「NoOps?よろしい ならば戦争だ」
●典型的な反応
・言葉が強い
肯定的 7,8割
否定的 2,3割
・NoOps は No Uncomfortable Ops
システム運用の嬉しくないことをなくす
●私から見たNoOpsの現状
・エンジンスタートした組織は数多い
言葉に共感して、チャレンジをはじめた
・光と影
登壇しているひとたちは、ギアを1速、2速、3速と入れたまぶしさ
歴史のある企業は 1速にも入らないことも多い
●もがく三景
・試行錯誤しにくい体制問題
・いいだしっぺが辛い問題
・旗だけ立っちゃう問題
-> エンプラで多い
先に組織だけできてしまう
まず標準化、ガイドライン、、、
いまやっていることを「やめよう」と
胸を張って言える組織ですか？
●マイクロソフト社内ITのクラウド移行
1. 退役 <- ここが重要
2. SaaSに移行 & 新規利用
3. PaaSに移行
4. IaaSに移行(最適化)
5. IaaSに移行(Lift&Shift)
今やっていることをやりながら
新しいことができますか？
●技術や組織はどんどん新しくなっている
・システム放っておいても複雑化し、やがて腐る
・やめる判断は、意思決定の権限がある人の大事な仕事
つくることばかり話す偉い人は危険
これをやめよう が必要
NoOpsの実践に必要なのは
ポジティブにやめる姿勢
●どうやって軌道にのせるか悩んでいるチームは多い
・いきなりドリームチームはつくれない
・意欲、パッションそれを持続する力を持つ少数ではじめる
・恣意的でも、小さくてもまず手を動かして実績をつくる
コアメンバーでつくるものを決めてから、メンバーを集める
●どこから着手するか決めきれない
・Cloud Native Trail Map
・でも Opsは順にやらなくていい
1. コンテナ化
いい感じのアプリや案件がないと、スタートできない
4. 監視と分析
Opsならここから
●Observability: 可観測性
・IaCから入る人が多い
効果が見えにくい
失敗したときのリスクが大きい
・知見、経験をためていくには監視から
変えても、止まってもユーザー影響は少ない
・Opsの道場になる
監視システムをNoOpsコンセプトでつくってみる
ここで知見を貯めて、ビジネスアプリケーションへ
●Reliabilityは曖昧
・SLIを議論しよう
Opsとビジネス側、アプリ側で議論しよう
雰囲気でやっていることには予算がつかない
SLIはNoOps活動の投資判断や評価の指標
●SLI/SLOを考える時
・ビジネスオーナーから見たら、高いほうが良い
・「適切なレベルの信頼性 - Microsoft Lean」
レベルは、ビジネスニーズに合致し、実用的である必要がある
共有指標があってこそのチームワーク
SLI、SLOがあると「これを守るために」で考えられる
●NoOps道を極めていくと
・Observabilityの重要性は高まっていく
・Netflix
Chaos Engineering 基盤: ChAP
セーフガードは 本番トラフィックの5%まで など
高い精度で計測していなければ実現できない
・きっちり計測して、ビジネス判断できることが大切
●NoOpsは文化
・技術やアーキテクチャだけではない
・前向きに「やめよう」が言えるチーム
これまで守ってきてくれてありがとう
・判断基準を数値で把握できるしくみ
SLI/SLO、Observability
・積極的に自分の仕事をなくしていこう
なくしてもなくしてもOpsの仕事はある
■チーム開発におけるDevとOpsのプラクティス
廣田 翼さん [KDDI]
●自己紹介
・KDDIのアジャイル開発センター
・はじめは運用から入りました
・開発と運用で組織が別れている
●スクラム開発と複数件運用でゴールが違う
・監視もリリースも自動化したい
統合システムに沿ってほしい
・チーム外の意見は後回しにせざるを得ない
どうしたら運用観点を早く注入できる
●運用するキーマンを開発チームに入れる
・非機能要件の優先度をPOやチームと調整
ユーザーストーリーと運用観点を同時に語れるように
週1くらいの定例会で運用チームから刺さる
これではバックログの優先度を上げられない
・運用もサービスをより良くする観点を持つ
●開発と運用でシステムの考え方にギャップがある
・システム構成要素をペット扱いする
-> 家畜扱い
問題があれば削除 & 自動回復
・SaaSのSLAへのこだわり
・監視設定がメンテしにくい
zabbixは設定したひと以外には分かりにくい
-> コード化 & CI/CD
みんなで確認しやすい
DataDog x terraformで実現
・リリース承認フローがガチガチ
通すためにサラリーマンスキルが必要
●現代のシステムは分散化され複雑
・機能や連携先が増減すると、システムの構成要素も変化
-> 各コンポーネント障害の影響範囲がわからない
・ユーザアクセスの傾向も時期によって変化
-> サービス員前に重厚なテスト
傾向が変わったら意味がないかもしれない
・システムは変化するべき、運用も変化するべき
-> 継続的に運用方法を見直すことが必要
●継続的障害訓練のススメ
・商用と同じ構成のステージング環境
・システムの弱点を把握、対策
・ステークホルダーも含めて障害フローを訓練
・訓練したい障害
プラットフォーム、サーバ、NW、DBなど全域
GUIで発生させて、状況を可視化
障害パターンを記憶して、再現
-> Gremlin
・Gremlin
SaaS
起こせる障害
リソース障害
ネットワーク障害
遅延の指定なども
ステート障害
NTPの同期をずらすなども
・障害訓練の内容
メモリ高負荷、時刻同期解除、DBアクセス遅延
AWSリソース / 外部システム / 内部間 のアクセスを 70%低下
-> 何を起こすかは秘密
・障害訓練の効果
コンポーネント障害時のユーザ影響がわかる
障害手順を修正、改善
システムを改善できる機械が生まれる
■LT: SRE はじめの一歩
平瀬 達也さん [JX通信社]
●JX通信社
・FASTALERT
・NewsDigest
-> 平和でないときほど落ちてはいけない
●開発チーム体制
・それぞれのプロダクトに各領域のエンジニアがいる
・開発がインフラに触れて運用もやる
-> ノウハウがチームに閉じる、属人化
●SREチームの役割
・同じ問題を二度解かない
・ドキュメント化、標準化、自動化
●災害時は高負荷なので負荷試験が大切
・CloudFormationで負荷試験環境を構築
・prod, stagingまでやるかは検討中
■LT: Slackによるインシデント対応
金城秀樹さん [コネヒト]
●小さいチーム
・インシデント発生時は、怖くて孤独
・整備されてない、マンパワー追い付かない
が、知っているメンバー
●slackで専用チャンネルを用意
・なぜ？
騒ぎ立て具合を見えやすく
時系列で追いやすい
・どう使う？
わかっていること、わかっていないこと
進展に応じて状況を連携
■LT: MLOps
中村 憲一郎さん [日本マイクロソフト]
●今日の話
・DevOpsができているとして
Opsのヒトは一人じゃ満足できない
・次はデータサイエンティスト
彼らはローカルでモデルをつくっている
-> MLOpsへ
●MLOps
・train model
・validate model
・deploy model
・monitor model
-> retrain model
※azureのサービスで、全部できますw
xOpsはたくさん
Opsはいろいろな場所で活躍するはず
■LT: Microservice x ScrumなBtoB Webアプリケーション開発現場のOps話
小西 宏樹さん [CyberAgent]
●前提
・BtoB webアプリ
・Microservices
・DevOps
・アジャイル開発
・組織
Microservices x Team
-> お客さんから見たら、1つのサービス
サービス（= チーム）間の不整合で問い合わせ
●挑戦したこと
・Ops面の作業を任せてみた
-> スプリントにはうまく組み込めない
・一時切り分けチームに振ってみた
-> コミュニケーションコストが増えた
●まとめ
・組織とアーキテクチャは鶏と卵
・オンコールを含めたスプリント計画
■LT: ZOZOTOWNを支えるチーム運用について
鶴見 純一さん [ZOZOテクノロジーズ]
●ZOZOTOWNリプレース
・モノリシック -> マイクロサービスへ
・オンプレ -> クラウドへ
・チーム
5人
PO、リーダー、メンバーx3
●CICD
・github
-> wecker
-> Container Registory
-> AKS
●監視と通知
・DataDog, NewRelic
・通知はslackでは気づけないことも
pagerdutyでオンコール
●まとめ
・メンバー全員に権限を与える
一人しかできない仕事を作らない
・それぞれ得意不得意が出てくる
認めあって、教え合う
背中を見て勝手に育つ、はナイ
■感想
監視システムをNoOpsコンセプトでつくってみる
影響が小さくて、成果が見えやすい。この後の展開でも、効果を測るために必要なしくみなので、構築後もカイゼンを続けられる。すてきなアプローチですね！CloudNativeジャーニーをはじめるチームに勧めていこうと思います！！
ハイプが起きている技術 -> 見極める -> 学ぶ -> エンプラに適用
自分の活動内容と重なって、毎回テーマに共感してしまう理由がわかった気がしました。
登壇者の皆さん、運営の皆さん ありがとうございました！
1周年おめでとうございます！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。