Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Ops meets NoOps

2 382 vues

Publié le

Tech-on MeetUp#07

Publié dans : Technologie
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y6a5rkg5 } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Ops meets NoOps

  1. 1. Ops meets NoOps 真壁 徹 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 2019/7/8 そのとき何が起こったか Tech-on MeetUp#07
  2. 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “インフラ & オープンソース”, “備考” : “NoOps Japan Community Supporter” }
  3. 3. お伝えしたい内容 NoOpsのインパクトを振り返る 光と影 ギアチェンジできない時は ドリームチームじゃなくていい 何から手をつけるか悩んだら
  4. 4. Ops Meets NoOps これまでの振り返り
  5. 5. “NoOps”のインパクト NoOps Japan Community発足からの反響 https://www.publickey1.jp/blog/18/noops_noopsops.html https://www.publickey1.jp/blog/18/noopsnoopsnoops_meetup_tokyo_1.html https://www.slideshare.net/ToruMakabe/noops-114039948
  6. 6. 言葉が強い 否定されてる 気がして嫌 いいぞ もっとやれ YesOps これだよこれ NoDev 仕事なくなっちゃ うのかなウチの偉い人へ 話してください NoOps はじめました
  7. 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. 8. 人が要らない(No)、ではなく やらなくていいことをなくす(No)
  9. 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の役割
  10. 10. エンジンスタートした組織は数多い Meetupの場に限らず、「チャレンジしてるよ!」という話を聞いたり相談されることが増えた ギアを1速から2速、3速へ入れたチームのまぶしさ 試行錯誤を通じて学び、前に進んでいる そして自走モードへ これからも経験を共有いただけると嬉しい でも、ギアがなかなか入らない組織のほうが多い 歴史の長い、資産の大きい企業ほど悩んでいる 今日の話はこちらにフォーカス わたしから見た NoOpsの現状
  11. 11. 試行錯誤しにくい体制問題 外注から内製への過渡期 継続的改善と請負契約の相性の悪さ いいだしっぺがつらい問題 インフラ主導のNoOpsに対して 「アプリ開発の増える工数を負担してくれるの?」 アプリ主導のNoOpsに対して 「じゃあアプリチームが運用して」 旗だけ立っちゃう問題 解決する具体的な課題の合意、経験や知見がないのに、組織が先にできちゃう その段階で標準化やガイドライン作成を求められる もがく三景
  12. 12. 考えてほしい ひとつのこと もし ギアチェンジができなければ
  13. 13. 「やめよう」と 胸を張って言える組織ですか?
  14. 14. やめた例: マイクロソフト社内ITのクラウド移行 やめることを決め、新たな挑戦に必要なリソースと余裕を得る <各システムの移行検討順> 1. 退役 2. SaaSに移行 & 新規利用 3. PaaSに移行 4. IaaSに移行(最適化) 5. IaaSに移行(Lift & Shift) NoOps的 腕の振るい どころ • オンプレミスにあった 60,000サーバーを撤廃し、 クラウドへ移行 • NoOpsな腕を振るう前に 「このシステムは退役で きないか」考える
  15. 15. いまやっていることを続けながら 新しいことができますか?
  16. 16. 何をするにも時間が必要 前向きにやめて 時間をつくろう システムは放っておいても複雑化し、やがて腐る 塩に漬けても、とりまく環境はどんどん変わるから システムが使命を果たしたら、寿命を迎えたら、リスペクトをもって退役を アプリやインフラだけじゃなく、プロセスや判断基準も放っておいたら腐る やめる判断は、偉い人の大事な仕事 つくるのは誰にでもできる 意思決定者が、NoOpsの文脈でつくる話に終始するのは危険信号 現場で「言っても無駄」とあきらめず、声をあげよう 前向きに「やめよう」と言えない組織に、心理的安全性、学ぶ文化はあるだろうか 言えない雰囲気であれば、NoOpsに取り組む環境ではないかもしれない
  17. 17. NoOpsの実践に必要なのは 技術力やツールの前に ポジティブな「やめヂカラ」
  18. 18. チェックリスト 歴史の長い会社ほど悩みがち 若い会社もいつかそうなるかも 出なくていい会議に呼ばれる/堂々 と欠席できない 「誰が」決めたか過度に気にする そのシステムや機能を、誰がどれ だけ使っているか把握していない ここ数年リフト&シフトやRPA、イ ンフラ単純更改ばかり
  19. 19. どうやって 軌道にのせるか 時間がつくれたら
  20. 20. いきなりドリームチームはつくれない はじめチョロチョロ なかパッパ でいい 少なくても、意欲あるメンバーではじめる その時点での能力よりも、Growth Mindset 「持続的な」変化に必要なのは、能力より意欲 恣意的でも、小さくても、まず手を動かして実績をつくる コアメンバーでつくるものを決めてから、チーム化したほうがいいかも (兼業も多い) FAQ「どんな実績がいいでしょうか」 うれしい/役立つものであれば、ちょっとした運用改善ツールでもいいのでは 周りを気にしてつくっても続かない 自分たちが「楽になったぜ…」「 捗るぜ…」としみじみ言えるものがいい
  21. 21. どこから着手するか 決めきれないなら
  22. 22. Cloud Native Trail Map https://github.com/cncf/trailmap クラウドが万能というわけでもないが、 CNCFは現在世界中の経験、知見、意見 が集まる場になっており、参考になる NoOps界隈で議論されている手法やア プローチも盛んに議論されている 典型的な取り組み順がTrail Map
  23. 23. でもOpsは 順にやらなくていい
  24. 24. ここからやってみる いい感じのアプリ や案件がないと、 スタートできない ここ
  25. 25. Observability 可観測性 ビジネスとそれを支える仕組みの状態を把握する 監視っちゃ監視だが、監視は行為、可観測性は性質 後付けではなく、監視される側が監視されやすい仕組みを意図的に備える 3大要素 メトリック、ロギング、トレーシング 事象を意味のあるデータに変え、判断や行動につなげる バズワードかもしれないが、使い方次第 × ベンダーが中身もないのに連呼する 〇 使い手が課題解決手段を合意するために活用する (グッとくる 背中を押す言葉)
  26. 26. なぜObservabilityからはじめるのか プロビジョニング/構成自動化よりはじめやすい、効果も出しやすい 監視が不要な組織はない と信じています エンドユーザーへの影響が小さい もし仮に止まった/やめた/変えたとしても影響は小さい Opsが仕様をコントロールできる Opsの道場となる 監視システムをNoOpsコンセプトでつくってみる Cloud Native Trail Mapに沿って監視システムを育てながら、知見を得る すぐに、小さくはじめられるオープンソースのツールやクラウドサービスはたくさんある
  27. 27. ところでSREの「R」、Reliabilityとは RELIABILITY FRESHNESS CORRECTNESS THROUGHPUT AVAILABILITY DURABILITY QUALITY COVERAGE LATENCY
  28. 28. SLI(Service Level Indicator)を議論しよう ビジネスを支える仕組みが健全かどうかの指標 監視 = リソースの死活や利用率だけではない サービスとしての死活 ユーザー体験に関わる指標 (スループット、遅延、HTTPステータスコード、etc) SLIはNoOps活動の投資判断や評価の指標になる 雰囲気に予算はつかない 雰囲気は評価されない NoOps活動で、やりたい、やるべきことを主張するための根拠を数値にする ビジネス主幹、プロダクトオーナーとの共通指標 (SLO: Service Level Objective) 投資や評価はSLI/SLOで客観的に判断する SLAまで持ち上げてペナルティの議論をするかは別問題 (社内でそれをやって機能するか?)
  29. 29. SRE の世界で行われている重要な観察は、100% 信頼できるシステムやサービスはほとんど存 在しないことです。 航空機、医療機器などの生死の状況は、注目すべき例外です。 実際、望ましい場合でもほとんどありません。 高い信頼性を求めるほど、高い信頼性を達成す るために必要な労力とリソースが (それに従ってコストも) 急増します。 言い方を変えると、 必要としていない信頼性を求めることは時間とお金の無駄です。 システム、サービス、製品に 適切なレベルの信頼性を達成することを考えます。 レベルは、ビジネス ニーズに合致し、実用的である必要があります。 たとえば、顧客が信頼 性が 100% ではない (たとえば、時間の最大 90% の) ネットワークを介して自社と接続してい る場合、自社のサービスが 95% の信頼性にするように労力とお金をかけることは、定義が示 すとおり、時間とお金の無駄です。 システム、サービス、製品に適切なレベルの信頼性を達成 することを考えます。 適切なレベルの信頼性– Microsoft Learn
  30. 30. SLI/SLOの議論/合意がないシステムで Opsは 雰囲気で可用性100%を要求されがち 投資も評価もされにくい
  31. 31. 共有指標があってこその チームワーク 外形監視 HTTPステータスコード < 400 99.xxx%/月間 SLI SLO ビジネス主幹 プロダクトオーナー Dev Ops • ピークでリソースが足り ないみたい、SLOを満た すにはもう少し投資が必 要かな • Opsが数値化してくれる から客観的に判断できる ね • とあるリクエストで多く エラーが起きてるみたい だ、アプリにトレースを 仕込もう • アプリ変更でSLOにどう 影響するかOpsに相談し よう • 先日エンドユーザーからク レームがあった時間のリソー ス利用率はxx%でした • 先月の障害ですが、SLOを満 たすようリカバリするには アーキテクチャー変更、投資 が必要と考えます たとえば
  32. 32. そして、NoOps道を究めていくと ますますObservabilityの重要性は高まっていく たとえばNetflixのChaos Engineering基盤 “ChAP” 故意、自動的に障害を起こし、回 復性を高める(常に鍛えている) セーフガードを定義している(本番 トラフィックの5%まで、など) 高い可観測性とビジネス判断なし には実現できない Automating chaos experiments in production - International Conference on Software Engineering (ICSE), 2019
  33. 33. まとめ
  34. 34. NoOpsは技術やアーキテクチャーだけじゃない 前向きに「やめよう」が言えるチームをつくろう 判断基準を数値で議論/合意しよう、把握する仕組みをつくろう SLI/SLO、 Observability 積極的に自分の仕事をなくしていこう 世の中は非効率にあふれているので、なくしてもなくしても、きっとOpsの仕事はある 「なくせるOps」の価値が高まっていく 大丈夫だ、問題ない まとめ
  35. 35. © Copyright Microsoft Corporation. All rights reserved.

×