Download as PDF, PPTX
![[Devsumi2017]オルタナティブなチーム開発のすゝめ](https://cdn.slidesharecdn.com/ss_thumbnails/devsumi2016-170217062111-thumbnail.jpg?width=640&height=640&fit=bounds)
Ops meets NoOps
- 1. Ops meets NoOps 真壁徹 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 2019/7/8 そのとき何が起こったか Tech-on MeetUp#07
- 2. 自己紹介 { “名前” : “真壁徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “インフラ & オープンソース”, “備考” : “NoOps Japan Community Supporter” }
- 3.
- 4.
- 5.
- 6.
- 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
- 8.
- 9. 先人/識者の経験、知見を共有 NoOps Meetup 直近3回の話題 CloudNative Buildpack シンプルに考えよう Zero Trust Network Zero Trust Networkで実現する制 約のないアプリケーションサー ビスともろもろ Elastic Stackでマイクロサービス 運用を楽にするには Observabilityを支える Stackdriver 物理データセンターでも NoOps NoOpsを実現するSREの存在意 義と役割 NoOps に入り込む基盤の負債 CircleCI 2.0を支えるインフラと SREの役割
- 10.
- 11.
- 12.
- 13.
- 14. やめた例: マイクロソフト社内ITのクラウド移行 やめることを決め、新たな挑戦に必要なリソースと余裕を得る <各システムの移行検討順> 1. 退役 2.SaaSに移行 & 新規利用 3. PaaSに移行 4. IaaSに移行(最適化) 5. IaaSに移行(Lift & Shift) NoOps的 腕の振るい どころ • オンプレミスにあった 60,000サーバーを撤廃し、 クラウドへ移行 • NoOpsな腕を振るう前に 「このシステムは退役で きないか」考える
- 15.
- 16.
- 17.
- 18.
- 19.
- 20. いきなりドリームチームはつくれない はじめチョロチョロ なかパッパ でいい 少なくても、意欲あるメンバーではじめる その時点での能力よりも、GrowthMindset 「持続的な」変化に必要なのは、能力より意欲 恣意的でも、小さくても、まず手を動かして実績をつくる コアメンバーでつくるものを決めてから、チーム化したほうがいいかも (兼業も多い) FAQ「どんな実績がいいでしょうか」 うれしい/役立つものであれば、ちょっとした運用改善ツールでもいいのでは 周りを気にしてつくっても続かない 自分たちが「楽になったぜ…」「 捗るぜ…」としみじみ言えるものがいい
- 21.
- 22. Cloud Native TrailMap https://github.com/cncf/trailmap クラウドが万能というわけでもないが、 CNCFは現在世界中の経験、知見、意見 が集まる場になっており、参考になる NoOps界隈で議論されている手法やア プローチも盛んに議論されている 典型的な取り組み順がTrail Map
- 23.
- 24.
- 25.
- 26. なぜObservabilityからはじめるのか プロビジョニング/構成自動化よりはじめやすい、効果も出しやすい 監視が不要な組織はない と信じています エンドユーザーへの影響が小さい もし仮に止まった/やめた/変えたとしても影響は小さい Opsが仕様をコントロールできる Opsの道場となる 監視システムをNoOpsコンセプトでつくってみる Cloud Native TrailMapに沿って監視システムを育てながら、知見を得る すぐに、小さくはじめられるオープンソースのツールやクラウドサービスはたくさんある
- 27.
- 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
- 30.
- 31. 共有指標があってこその チームワーク 外形監視 HTTPステータスコード＜ 400 99.xxx%/月間 SLI SLO ビジネス主幹 プロダクトオーナー Dev Ops • ピークでリソースが足り ないみたい、SLOを満た すにはもう少し投資が必 要かな • Opsが数値化してくれる から客観的に判断できる ね • とあるリクエストで多く エラーが起きてるみたい だ、アプリにトレースを 仕込もう • アプリ変更でSLOにどう 影響するかOpsに相談し よう • 先日エンドユーザーからク レームがあった時間のリソー ス利用率はxx%でした • 先月の障害ですが、SLOを満 たすようリカバリするには アーキテクチャー変更、投資 が必要と考えます たとえば
- 32. そして、NoOps道を究めていくと ますますObservabilityの重要性は高まっていく たとえばNetflixのChaos Engineering基盤 “ChAP” 故意、自動的に障害を起こし、回 復性を高める(常に鍛えている) セーフガードを定義している(本番 トラフィックの5％まで、など) 高い可観測性とビジネス判断なし には実現できない Automating chaosexperiments in production - International Conference on Software Engineering (ICSE), 2019
- 33.
- 34.
- 35. © Copyright MicrosoftCorporation. All rights reserved.