より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標 - Qiita
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ～、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの？という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか？それをまとめてみましたので、ご覧ください
DevOpsDays Tokyo2022 ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 #DevOpsDaysTokyo #DevOps #4keys #cloud #cicd #Accelerate #LeanとDevOpsの科学
DevOpsDays Tokyo2022 ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 #DevOpsDaysTokyo #DevOps #4keys #cloud #cicd #Accelerate #LeanとDevOpsの科学
生産性を可視化したい！ / SUZURI's four keys
@Pepabo Tech Conference #15 - ECプラットフォームSUZURIの開発の裏側 https://pepabo.connpass.com/event/215058/
フィーチャーフラグ（Feature Flag）はなぜ必要なのか？
本連載は、最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグ（Feature Flag）について、概要や導入方法、ベストプラクティスを紹介します。第1回は、フィーチャーフラグとはなにか、どのようにしてプロダクト開発を変えていくのか、そのメリットと導入の際の懸念点を説明します。 はじめに 本連載はフィーチャーフラグについての連載です。最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグに焦点をあて、フィーチャーフラグとは何なのか、どういった機能を提供するのか。フィーチャーフラグのメリット・デメリットを、具体例を使って詳細に説明します。また、導入前に考慮すべきことや、フィーチャーフラグの実装、サービスの選定の際の注意点、効率よく、かつ継続的に使用していくためのベストプラクティスも併せて解説します。さらにはサードパーティー製のフィーチャーフラグサービスの比較を行
DevOpsカルチャーのKPI - kawasima
このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。
Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜
はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに？ Four Keys とは なぜ Fo
Maximizing Developer Effectiveness
Technology is constantly becoming smarter and more powerful. I often observe that as these technologies are introduced an organization’s productivity instead of improving has reduced. This is because the technology has increased complexities and cognitive overhead to the developer, reducing their effectiveness. In this article, the first of a series, I introduce a framework for maximizing develope
Online DevOps Dojo
Online DevOps Dojo The Online DevOps Dojo is a novel set of hands on learning modules which cover both cultural and technical aspects of DevOps. The modules are hosted on GitHub and executed from the Katacoda platform. They can be run from your browser without any download or configuration. Informed by research on how people learn, the DevOps Dojo curriculum incorporates storytelling and emphasize
アジャイルとDevOpsの品質保証と信頼性 - Test Automation
このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 （品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。） --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル
DevOpsって何だろう？ / What is DevOps? by JFrog
ブログエントリはこちら！: https://blog.jfrog.co.jp/entry/what-is-devops-for-jfrog
DevOpsとSREの違いとは?
ビズリーチのSREチームでJenkinsおじさんとマネジメントを担当している阪本です。もう先月の話になりますが、サンフランシスコで開催されたGoogle Cloud Next ‘18に参加してきました。今回はその場で何度も聞いた class SRE implements DevOps という考え方を紹介させて頂きます。DevOpsとSREの関係性を理解する上で大変参考になりました。 DevOps、SREという単語が使われるようになって時間が経ちましたが、若干のバズワード感も否めず私自身混乱していました。そのような中でSREの草分け的存在であるGoogleが新たに class SRE implements DevOps というメッセージを発信し始めました。これは「SREはDevOpsというinterfaceの実装である」という意味で、いわゆるプログラミング言語の抽象化機能であるinterfa
O'Reilly Velocity Conference 2019 San Jose参加レポート
こんにちは、技術開発室の與島です。 2019年6月11日〜13日にカリフォルニア州サンノゼで開催されたO'Reilly Velocity Conference 2019 San Joseに、弊社から細田、伊藤、與島の3名が参加してきました。 ハートビーツではここ数年、毎年この時期に行われるO'Reilly Velocity Conferenceに参加しています。 なお、Velocity Conferenceは主に運用やDevOps向けのイベントになります。 本記事では興味深かったセッションをいくつか紹介します。 なお、内容については紹介している資料を確認してください。聞き間違えたり、認識が違っているかもしれないためです。 Production Engineering, SRE, and DevOps Move fast and learn from incidents 資料: なし 下記の
SIerの生き残り戦略としてのDevOps システム運用の社葬から - Qiita
この記事に出てくる「当社」や「顧客」その他はフィクションです。ポエムです。実在のものとは関係ありません。 一部ではエンジニアの供給源として早く滅びろとまで言われているSIer、その中でも何ら価値を生み出さないゾンビ扱いのSIerのシステム運用が、もし生き延びることが出来るとしたらどんな姿なのかを考えてみるだけのポエムです。 ダラダラ書きますので、お付き合いしたいひとだけどうぞ。 社葬は嫌でもSIerで運用が好きという変態さんには、下記などを。 オカンや嫁をコアにするのではなく、システム運用をコアにしたドメイン駆動設計を、という差し迫った夢です。 システム運用のドメイン駆動設計、または運用の抽象化（とりあえず背景「SIerの伝統的な運用」） システム運用のドメイン駆動設計、または運用の抽象化（ドメインを隔離する） とりあえず、Qiitaを読んでる方が、いわゆるDevOpsやアジャイルという言
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Team Topologies | Atlassian
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
インフラ自動化の落とし穴と宣言的アーキテクチャ
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
GitHub - theonedev/onedev: Git Server with CI/CD, Kanban, and Packages. Seamless integration. Unparalleled experience.
DevOps capabilities | Cloud Architecture Center | Google Cloud
DevOps導入指南～基本編～
