#author("2023-05-31T15:28:59+09:00","default:irrp","irrp")
→システム運用
→[[CI/CD]]
→アジャイル
→インシデント管理ツール
#contents
*概念の整理/SREとDevOpsの違い [#t07efb90]
-[[SRE vs Devops vs Platform Engineering | The New Stack>https://thenewstack.io/sre-vs-devops-vs-platform-engineering/]] 2023.1
-CI/CDは、アプリケーションやサービスの開発プロセスにおいて、開発者がコードを継続的にリポジトリにマージし、自動的にテストやビルド、デプロイが行われるようにすることを目的としたプラクティスです。CI/CDを採用することで、開発者はより頻繁に新しいコードをリリースできるようになり、スピード感を向上させることができます。
-DevOpsは、開発 (Development) と運用 (Operations) の両部門を統合し、連携を促進することを目的としたアプローチです。DevOpsは、開発プロセスを効率化することだけではなく、運用やリリース管理のプロセスを改善することも目的としています。DevOpsを採用することで、開発プロセスと運用プロセスの融合を図り、スピード感を向上させることができます。
-[[DevOpsとは。アジャイル開発、CI/CDとの違いも解説 | Winserverのススメ>https://www.winserver.ne.jp/column/about-devops/]] 2022.4
-[[SREとDevOpsの違いはなにか>https://sreake.com/blog/sre-vs-devops/]] 2021.8
--DevOps＝思想、SRE＝実装
-[[DevOpsとは何か？そのツールと組織文化、アジャイルとの違い>http://www.buildinsider.net/enterprise/devops/01]] 2016
*DevOps [#b0a1a6e2]
-[[DevOpsの導入時に考えたい4つのこと ｜ もふもふ技術部>https://tech.mof-mof.co.jp/blog/devops-get-started/]] 2023.3
-[[これだけは知っておきたい カテゴリーの記事一覧 - とことんDevOps | 日本仮想化技術が提供するDevOps技術情報メディア>https://devops-blog.virtualtech.jp/archive/category/%E3%81%93%E3%82%8C%E3%81%A0%E3%81%91%E3%81%AF%E7%9F%A5%E3%81%A3%E3%81%A6%E3%81%8A%E3%81%8D%E3%81%9F%E3%81%84]] 2023.2
-[[国内企業のDevOps／開発プラットフォーム ユーザー動向に関する最新の調査結果を発表>https://www.idc.com/getdoc.jsp?containerId=prJPJ49999523]] 2023.1
--2017年から国内企業のDevOps実践状況について調査していますが、DevOpsの実践率は年々上昇し続けており、2022年の調査では59.3％の実践率
--DevOpsの実践を計画、または評価、検討していると回答した企業は21.7％
-[[DockerでDevOps環境を整える - Qiita>https://qiita.com/rsm223_rip/items/679003815821ae335458]] 2022.11
--Redmine, GitLab
-[[知っておくべきDevOpsの「4つの原則」 | Think IT（シンクイット）>https://thinkit.co.jp/article/19985]] 2022.11
--ソフトウェア開発ライフサイクルの自動化
--コラボレーションとコミュニケーション
--継続的な改善と無駄の最小化
--短いフィードバックループでユーザーのニーズに集中
-[[闇のDevOps DevOpsと業績評価. 先日、NTT Tech… | by ところてん | Medium>https://tokoroten.medium.com/%E9%97%87%E3%81%AEdevops-devops%E3%81%A8%E6%A5%AD%E7%B8%BE%E8%A9%95%E4%BE%A1-5aff8b60f589]] 2017
--DevOpsは、プログラミングができるDevの人がOps業務の一部を自動化できるようになる、というものであり、プログラミングのできないOpsの人がDevをできるようになる仕組みではありません。Opsだけやってきた子会社がDevOpsなツールを導入すれば、DevOpsができる会社になるわけではありません。
--大企業において、本当にDevOpsをやりたいのであれば、それはプログラミングのできない手作業Opsの人材のクビを切り、Opsの会社を潰すことを検討せねばなりません。DevOpsとは情報産業の垂直統合なのです。
--この覚悟がないまま、適当なツールだけ導入してDevOpsと言ってお茶を濁すのはそろそろやめましょう。
-[[DevOpsとは？概要・重要性・メリット・アジャイルとの違いを解説>https://www.techfirm.co.jp/blog/devops]] 2022.10
-[[DevOpsはここから始めよう | Think IT（シンクイット）>https://thinkit.co.jp/article/19915]] 2022.10
-[[開発スピードの速い企業は品質が高く、遅い企業は品質が低い。和田卓人氏による「組織に自動テストを根付かせる戦略」（その2）。ソフトウェア品質シンポジウム2022 − Publickey>https://www.publickey1.jp/blog/22/22022_1.html]] 2022.9
-[[DevOps Simplified - DEV Community>https://dev.to/patilganesh1010/devops-simplified-j12]] 2022.7
-[[DevOps Roadmap: Learn to become a DevOps Engineer or SRE>https://roadmap.sh/devops]] 2022.6
-[[Azureで実現できるDevOps環境を調べてみた【SREの登竜門】 - RAKUS Developers Blog | ラクス エンジニアブログ>https://tech-blog.rakus.co.jp/entry/20220726/azure]] 2022.7
-[[Azure DevOps で UE5 プロジェクトを自動ビルド化してみる - Qiita>https://qiita.com/akiojin/items/e04ad43ab09317799bfb]] 2022.6
-[[「無人化システム」を駆逐する組織マネジメントとエンジニアリング>https://zenn.dev/tmknom/articles/93f227ad5e55aa]] 2021.6
-[[DevOpsとは、なんなのか？ - arclamp>https://arclamp.hatenablog.com/entry/2022/01/06/122829]] 2022.1
-[[DevOpsなんてくそくらえ>http://razokulover.hateblo.jp/entry/2013/10/17/230900]] 2013.10
-[[いまさら聞けない「DevOps」 (1/2)>http://www.atmarkit.co.jp/ait/articles/1307/02/news002.html]] 2013.7.2
*Four Keys [#a8f95008]
-[[「推測するな、計測せよ」 〜小さく始める生産性可視化と分析〜 - Speaker Deck>https://speakerdeck.com/naopr/tui-ce-suruna-ji-ce-seyo-xiao-sakushi-merusheng-chan-xing-ke-shi-hua-tofen-xi]] 2023.5
-[[Four keys指標とは - Mirai Translate TECH BLOG>https://miraitranslate-tech.hatenablog.jp/entry/2023/03/20/070000]] 2023.3
-[[100人規模のエンジニア組織で DevOps Four Keys を導入し、アジリティー向上を目指した取り組み - MonotaRO Tech Blog>https://tech-blog.monotaro.com/entry/2022/12/13/090000]] 2022.12
-[[エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ>https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance]] 2020.9
--デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
--変更のリードタイム - commit から本番環境稼働までの所要時間
--変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
--サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
-[[開発組織の生産性を可視化するState of DevOpsとFour Keysとは(増補改訂版) / Introduction to State of DevOps and Four Keys for Visualizing Productivity in Development Organizations expanded and revised edition - Speaker Deck>https://speakerdeck.com/isanasan/introduction-to-state-of-devops-and-four-keys-for-visualizing-productivity-in-development-organizations-expanded-and-revised-edition]] 2022.9
--1.デプロイ頻度...コードの変更を本番環境へリリースする頻度
--2.リードタイム...コードのコミットから本番稼働までの所要時間
--3.MTTR...インシデント発生から復旧までかかる平均時間
--4.変更失敗率...デプロイ起因で本番障害が発生する割合
--1,2がスピードのメトリクス、3,4が品質のメトリクス
--品質とスピードにトレードオフはない
--&ref(システム運用/4keys.png);
*SRE [#gdb317cd]
-[[組織に対してSREを適用するとどうなるか - Speaker Deck>https://speakerdeck.com/kuniim/zu-zhi-nidui-sitesrewoshi-yong-surutotounaruka]] 2023.2
-[[SREチームはDevOpsに向き合い、開発を加速させる>https://zenn.dev/biosugar0/articles/sre-implements-devops]] 2022.12
-[[Google - Site Reliability Engineering>https://sre.google/books/]] 2022.10
-[[SRE導入: システムを安定させる4000万円の魔法の壺 - MonotaRO Tech Blog>https://tech-blog.monotaro.com/entry/2022/09/13/090000]] 2022.9
-[[インフラエンジニアとSREエンジニアは何故混同されるのか - Qiita>https://qiita.com/paprika-mah/items/38f38cf0cee78c571b2e]] 2022.5
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
