ジュニアエンジニアはSREとどう向き合うべきか

Transcript

1. ジュニアエンジニアはSREとどう向き合うべきか 〜NRIネットコム TECH AND DESIGN STUDY #99〜 2026年05月19日 NRIネットコム株式会社 NTシステム事業二部 柴原 佑哉
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 柴原 佑哉（しばはら ゆうや） ◼ NRIネットコム株式会社 ⚫ NTシステム事業二部 ◼ クラウドインフラエンジニア ⚫ AWSメイン ⚫ Terraform・AWS CDK ⚫ Webシステムの設計・構築 ◼ Like ◼ 資格 ⚫ AWS Certified AI Practitioner ⚫ AWS Certified Cloud Practitioner ⚫ AWS Certified Solutions Architect – Associate ⚫ AWS Certified Solutions Architect – Professional 自己紹介 ◼ ブログ ⚫ 新人エンジニアはIaCとどう向き合うべきか ⚫ 知識ゼロからTerraformで実装するときに知っておくと 便利なTips #nncstudy AWS Cloud Development Kit (AWS CDK)
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. はじめに #nncstudy
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. ジュニアエンジニア不要論が謳われる中で ◼ AIの発展によって、ジュニアエンジニア不要論がしばしば謳われている ⚫ AI1つでジュニア1人分以上のアウトプット ⚫ パフォーマンス・モチベーションの揺らぎ ⚫ ジュニア1人にかける教育の金銭的・時間的なコストが高い ◼ ジュニアエンジニアとしての課題感 ⚫ コーディング・ドキュメンテーションの機会の減少 ⚫ 開発スピードと技術理解のトレードオフの発生 ⚫ 自分のタスクがなくなるのではないかという漠然とした不安 ◼ 解決策（？） ⚫ アウトプットと自身の知識・経験とのギャップは前提として、説明責任は果たせるように努力する ⚫ マインドとしては上流にシフトし、顧客やユーザー・非機能要件などを意識する ⚫ 自分でタスクを巻き取っていくモチベーションの維持 必然と上流工程の意識を求められる時代になっているのでは？ じゃあ自分より上流をやっている上司は何を考えているのか？ #nncstudy
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 経験に則った、後の運用を考慮した判断の例 Case 1 ◼ 自分「Terraformのディレクトリ構成を考えてみたのですが、ご意見いただけますでしょうか？」 ◼ 上司「この構成でも別に問題はないけど、後の運用が大変になったり、可読性が低くなったりするかもね」 → IaCの運用とチーム全体としての開発体験の意識 Case 2 ◼ 自分「キャッシュサーバについては、このスペックと構成でいこうと思うのですが問題ないでしょうか？」 ◼ 上司「今回のプロダクトは耐障害性が求められてるから、安全性を担保するためにノードは増やしておいて」 ◼ 上司「その方が運用もラクになるし、お客さんも安心だと思うよ」 → 運用容易性や顧客の体験によるアーキテクチャ判断 #nncstudy
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. このような上司の視点を学べることはできないのか ◼ DevOpsは、開発と運用のあるべき姿のような話でざっくりとしかわかっていない ◼ もう少しインフラ寄りな話で、より実践的なものはないのか？ → SREというものがあるらしい #nncstudy
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. SREとは？ 01 信頼性を制御するために 02 ジュニアエンジニアはSREとどう向き合うべきか 03 まとめ 04 #nncstudy
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 01. SREとは？ #nncstudy
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. SRE (Site Reliability Engineering: サイト信頼性エンジニアリング) ◼ Googleによって提唱 ◼ 各要素を分解してみる 01. SREとは？ “SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの” （引用：O’Reilly Japan 『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』） Site Webサイトに限らず システム・サービス全体のこと Reliability ユーザーがSiteを期待通り 利用可能か Engineering 技術で最適化する ユーザーがシステム・サービスを期待通り利用できるために、 運用業務にソフトウェアエンジニアリングの手法を応用するための実践 #nncstudy
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. DevOpsとの違い ◼ DevOpsとは？ ◼ 違い 01. SREとは？ “ DevOps is a loose set of practices, guidelines, and culture designed to break down silos in IT development, operations, networking, and security. ” DevOpsは、IT開発、運用、ネットワーク、セキュリティのサイロ化を打破するために設計された 緩やかな実践、ガイドライン、文化の集合体です。 （引用：https://sre.google/workbook/how-sre-relates/） #nncstudy DevOps 全体的なプラクティスや文化の 集合体 SRE DevOpsの 職務としての役割・実践 職務としてのSRE → SREs 手法としてのSRE → SREing
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. SREをする目的・モチベーション 01. SREとは？ ◼ 信頼性を制御してユーザーや開発者の体験を最適化し、ビジネス価値を最大化する ⚫ SLO/SLAによる定量的な定義 ⚫ IaCによる運用の省力・自動化 ⚫ 信頼性がビジネス・ブランドに与える影響の理解 #nncstudy ◼ 開発チームと協力し、アジリティも両立させる ⚫ 信頼性100%を目指さない ⚫ 新規・追加機能を拒否しない ⚫ CI/CDの整備 ◼ 複雑なシステムの成長に比例して運用メンバーも過剰に増加しないようにする ⚫ オブザーバビリティを高める ⚫ トイルの削減 ⚫ 持続可能な運用文化の醸成
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. 02. 信頼性を制御するために #nncstudy
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. SLOの実装 ◼ SLO（Service Level Objective: サービスレベル目標） ⚫ サービスの信頼性に対する目標レベルを定義 ⚫ 信頼性に関するデータ駆動型の意思決定において重要な役割を果たし、SREの実践の中心となる ⚫ “SLOがなければSREは必要ないとさえ言えるでしょう。” （引用： https://sre.google/workbook/how-sre-relates/ ） ◼ SLOを定義するためのもの ⚫ SLI（Service level Indicator: サービスレベル指標） • 信頼性のための目標値 • Ex) 成功したHTTPリクエスト数 / 総HTTPリクエスト(成功率) ⚫ SLA（Service level Agreement: サービスレベル合意） • サービス提供者と利用者間で契約した合意事項 • SLOを達成することでSLA順守も達成される設計 ⚫ エラーバジェット • SLOに対して許容される失敗の量 • 使い果たしたら再びSLOに戻るまでどうするかの意思決定への活用 02. 信頼性を制御するために #nncstudy SLI 時間 SLO エラーバジェット
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. モニタリングとオブザーバビリティ ◼ モニタリング（監視） ⚫ システムのメトリクス、ログなど様々なデータをリアルタイムに収集することで、システムの異常を検知する ◼ オブザーバビリティ（可観測性） ⚫ システムの内部構造を深く理解して、予期せぬ問題に対しても迅速に対応できる能力 ◼ オブザーバビリティが低いとどうなるのか ⚫ 根本原因が特定できず、MTTR（復旧までの時間）が長くなる ⚫ 勘や経験による切り分けに頼り、属人化する ⚫ 変更の影響が分からない ⚫ プロダクトの判断が感覚ベースになる etc. ◼ オブザーバビリティを高めるためのツール ⚫ メトリクス：Amazon CloudWatch / Datadog / New Relic … ⚫ ログ：CloudWatch Logs / Loki … ⚫ トレース：AWS X-Ray / Jaeger … → これらを組み合わせて、様々な問題に迅速に対応できるようにする 02. 信頼性を制御するために #nncstudy Amazon CloudWatch AWS X-Ray
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. ポストモーテム ◼ ポストモーテム ⚫ 発生したシステム障害やインシデントから得られた教訓を体系的にまとめて、その学びをチームや組織で振り返る プロセスやドキュメントのこと ⚫ 小さな障害・インシデントやヒヤリハットについてもポストモーテムを実施することで、再発を予防する ⚫ 再発防止のための具体策（アクションアイテム）を明確にする ⚫ アクションアイテムの有効性を継続的に確認し、ポストモーテムが形骸化しないように運用する ◼ ポストモーテムの目的とそのための文化醸成 02. 信頼性を制御するために 障害 インシデント 対応 ポストモーテム アクションアイテム の特定 継続的に見直し #nncstudy 目的 • 障害を再発させないための学びを得ること • 同じ問題を繰り返さない 文化醸成 • 障害は起きるものという前提 • 個人のミスではなく原因にフォーカスする • 組織の運用レベルを向上させる資産
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. トイル管理 ◼ トイル ⚫ 手作業であり繰り返し発生する運用業務のうち、自動化可能なタスク • Ex) 手動デプロイ / 手動パッチ / 手動リカバリ etc. ◼ 6つの特性を持つとされ、該当すればそれはトイルの可能性 （引用：O’Reilly Japan 『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』） ◼ トイル削減の目的 ⚫ 本来やるべきことへの集中 ⚫ 人為ミスの削減 ⚫ システムの成長に比例した運用人数の増加の抑制 ◼ トイル削減の実践 ⚫ トイルの見える化を行う ⚫ 小さく初めて徐々に改善・自動化していく ⚫ やりすぎない、自動化におけるリスクの評価は行う 02. 信頼性を制御するために 手作業 繰り返し 自動化可能 非戦術的 持続的価値がない システム成長と同様か それ以上に増加 #nncstudy
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. 03.ジュニアエンジニアはSREとどう向き合うべきか #nncstudy
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. ジュニアエンジニア目線でのSREの難しさ ◼ あるべき姿がわからない ⚫ 知識・経験不足なので先の見通しが悪い ⚫ どこまで信頼性を担保するのか・何に備えるべきなのかわからない部分が多い ⚫ 「チーム・人・要件による」 • 答えはない • 何を参考にすればいいの？ 03.ジュニアエンジニアはSREとどう向き合うべきか #nncstudy ◼ 身近なSREsを探してロールモデルにする ⚫ 先輩たちは、少なくとも自分よりはSREなはず ⚫ 身近な人をロールモデルにすると成長効果が高い ⚫ 「ロールモデルにしたい」と思えることもその人の信頼性によるもの
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. ジュニアエンジニア目線でのSREの難しさ ◼ 運用課題の優先順位の付け方 ⚫ 信頼性100%を目指さないのは理解した ⚫ でも問題は多くある ⚫ オブザーバビリティが低ければ隠れたコアな問題がネックになるかも ⚫ では数ある問題の中からどれから着手すれば良いのか？ 03.ジュニアエンジニアはSREとどう向き合うべきか #nncstudy ◼ 小さな改善から始めて、その効果を測る ⚫ 自分の小さいタスクのトイルを洗い出して自動化してみる ⚫ 自分の技術とAIで押し切れる部分ではある ⚫ チーム内の課題に拡大していけば信頼性にもつながる
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. ジュニアエンジニア目線でのSREの難しさ ◼ 対顧客・ビジネス直通の信頼性制御のハードルが高い ⚫ そもそも裁量がない ⚫ エラーバジェットによるプロダクトのリリース判断などはまだ難しい ⚫ 品質とデリバリーに集中しがちで、ビジネスに関わるコストの意識が下がる 03.ジュニアエンジニアはSREとどう向き合うべきか #nncstudy ◼ まずはチーム内の信頼性をエンジニアリングする ⚫ 「小さく始める」に則って、まずはチーム内から ⚫ 運用のための振り返りの文化醸成、トイル削減による開発体験向上 ⚫ 小さくても前向きな改善が信頼性・ビジネス価値につながる（と信じる）
21. 20 Copyright（C） NRI Netcom, Ltd. All rights reserved. ジュニアエンジニア目線でのSREの難しさ ◼ どうしても難しい部分 →ソフトウェア工学的でない信頼性の部分 ◼ 有能感、ベテラン感のような感覚的な信頼性 ⚫ 「この人に任せておけば大丈夫」 ⚫ 「こいつ、できる…！」 →考えない。（いつかなれるようにがんばる） 03.ジュニアエンジニアはSREとどう向き合うべきか #nncstudy
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. 04.まとめ #nncstudy
23. 22 Copyright（C） NRI Netcom, Ltd. All rights reserved. ジュニアエンジニアはSREとどう向き合うべきか ◼AIの発展により、必然とジュニアエンジニアは上流工程の意識を持つ必要が出てきているのではないか ◼SRE：信頼性を制御してユーザーや開発者の体験を最適化し、ビジネス価値を最大化する ◼ジュニアエンジニアはSREとどう向き合うべきか ⚫ 身近なSREsを探してロールモデルにする ⚫ 小さな改善から始めて、その効果を測る ⚫ まずはチーム内の信頼性をエンジニアリングする 04.まとめ #nncstudy