Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Ops meets NoOps
Similar to Ops meets NoOps (20)
More from Toru Makabe
More from Toru Makabe (20)
Recently uploaded
Recently uploaded (14)
Ops meets NoOps
- 1. Ops meets NoOps 真壁 徹 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 2019/7/8 そのとき何が起こったか Tech-on MeetUp#07
- 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “インフラ & オープンソース”, “備考” : “NoOps Japan Community Supporter” }
- 7. NoOpsはNo Uncomfortable Ops（システム運用の嬉しくないことを なくす）を目指すための技術、アーキテクチャ、それを実現するため の活動を指します。このアプローチの代表例に、コンテナを活用した 高回復性設計、DevOpsの活用、モニタリングと構成設定の自動化、 SREによるToil削減活動、などがあります。 NoOpsを実現するためのシステムが備えるべき代表的な能力には、高 い回復性、可観測性、構成可能性、安全性の担保があります。これら NoOpsの能力を活用することで、例えば、Self-Healing、In-flight renewing, Adaptive Scale, Safety Everywhereなどのエクスペリエンス を実現することが可能になります。 NoOps Definition v1.0 - NoOps Japan Community
- 9. 先人/識者の経験、知見を共有 NoOps Meetup 直近3回の話題 Cloud Native Buildpack シンプルに考えよう Zero Trust Network Zero Trust Networkで実現する制 約のないアプリケーションサー ビスともろもろ Elastic Stackでマイクロサービス 運用を楽にするには Observabilityを支える Stackdriver 物理データセンターでも NoOps NoOpsを実現するSREの存在意 義と役割 NoOps に入り込む基盤の負債 CircleCI 2.0を支えるインフラと SREの役割
- 14. やめた例: マイクロソフト社内ITのクラウド移行 やめることを決め、新たな挑戦に必要なリソースと余裕を得る <各システムの移行検討順> 1. 退役 2. SaaSに移行 & 新規利用 3. PaaSに移行 4. IaaSに移行(最適化) 5. IaaSに移行(Lift & Shift) NoOps的 腕の振るい どころ • オンプレミスにあった 60,000サーバーを撤廃し、 クラウドへ移行 • NoOpsな腕を振るう前に 「このシステムは退役で きないか」考える
- 20. いきなりドリームチームはつくれない はじめチョロチョロ なかパッパ でいい 少なくても、意欲あるメンバーではじめる その時点での能力よりも、Growth Mindset 「持続的な」変化に必要なのは、能力より意欲 恣意的でも、小さくても、まず手を動かして実績をつくる コアメンバーでつくるものを決めてから、チーム化したほうがいいかも (兼業も多い) FAQ「どんな実績がいいでしょうか」 うれしい/役立つものであれば、ちょっとした運用改善ツールでもいいのでは 周りを気にしてつくっても続かない 自分たちが「楽になったぜ…」「 捗るぜ…」としみじみ言えるものがいい
- 22. Cloud Native Trail Map https://github.com/cncf/trailmap クラウドが万能というわけでもないが、 CNCFは現在世界中の経験、知見、意見 が集まる場になっており、参考になる NoOps界隈で議論されている手法やア プローチも盛んに議論されている 典型的な取り組み順がTrail Map
- 23. でもOpsは 順にやらなくていい
- 26. なぜObservabilityからはじめるのか プロビジョニング/構成自動化よりはじめやすい、効果も出しやすい 監視が不要な組織はない と信じています エンドユーザーへの影響が小さい もし仮に止まった/やめた/変えたとしても影響は小さい Opsが仕様をコントロールできる Opsの道場となる 監視システムをNoOpsコンセプトでつくってみる Cloud Native Trail Mapに沿って監視システムを育てながら、知見を得る すぐに、小さくはじめられるオープンソースのツールやクラウドサービスはたくさんある
- 28. SLI(Service Level Indicator)を議論しよう ビジネスを支える仕組みが健全かどうかの指標 監視 = リソースの死活や利用率だけではない サービスとしての死活 ユーザー体験に関わる指標 (スループット、遅延、HTTPステータスコード、etc) SLIはNoOps活動の投資判断や評価の指標になる 雰囲気に予算はつかない 雰囲気は評価されない NoOps活動で、やりたい、やるべきことを主張するための根拠を数値にする ビジネス主幹、プロダクトオーナーとの共通指標 (SLO: Service Level Objective) 投資や評価はSLI/SLOで客観的に判断する SLAまで持ち上げてペナルティの議論をするかは別問題 (社内でそれをやって機能するか？）
- 29. SRE の世界で行われている重要な観察は、100% 信頼できるシステムやサービスはほとんど存 在しないことです。 航空機、医療機器などの生死の状況は、注目すべき例外です。 実際、望ましい場合でもほとんどありません。 高い信頼性を求めるほど、高い信頼性を達成す るために必要な労力とリソースが (それに従ってコストも) 急増します。 言い方を変えると、 必要としていない信頼性を求めることは時間とお金の無駄です。 システム、サービス、製品に 適切なレベルの信頼性を達成することを考えます。 レベルは、ビジネス ニーズに合致し、実用的である必要があります。 たとえば、顧客が信頼 性が 100% ではない (たとえば、時間の最大 90% の) ネットワークを介して自社と接続してい る場合、自社のサービスが 95% の信頼性にするように労力とお金をかけることは、定義が示 すとおり、時間とお金の無駄です。 システム、サービス、製品に適切なレベルの信頼性を達成 することを考えます。 適切なレベルの信頼性– Microsoft Learn
- 31. 共有指標があってこその チームワーク 外形監視 HTTPステータスコード ＜ 400 99.xxx%/月間 SLI SLO ビジネス主幹 プロダクトオーナー Dev Ops • ピークでリソースが足り ないみたい、SLOを満た すにはもう少し投資が必 要かな • Opsが数値化してくれる から客観的に判断できる ね • とあるリクエストで多く エラーが起きてるみたい だ、アプリにトレースを 仕込もう • アプリ変更でSLOにどう 影響するかOpsに相談し よう • 先日エンドユーザーからク レームがあった時間のリソー ス利用率はxx%でした • 先月の障害ですが、SLOを満 たすようリカバリするには アーキテクチャー変更、投資 が必要と考えます たとえば
- 32. そして、NoOps道を究めていくと ますますObservabilityの重要性は高まっていく たとえばNetflixのChaos Engineering基盤 “ChAP” 故意、自動的に障害を起こし、回 復性を高める(常に鍛えている) セーフガードを定義している(本番 トラフィックの5％まで、など) 高い可観測性とビジネス判断なし には実現できない Automating chaos experiments in production - International Conference on Software Engineering (ICSE), 2019
- 33. まとめ
- 35. © Copyright Microsoft Corporation. All rights reserved.