2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきましたRead less
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説(前編)。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
こんにちは。弊社のエンゲージメントサーベイ製品HR Spannerのリードエンジニアを担当している岡部です。昨今注目されているDevOpsとそのケイパビリティについて、およそ一年前に社内の勉強会で発表を行ないました。今回の機会に、こちらでも寄稿させていただきたいと思います。 元になっている書籍は比較的大規模な開発を対象にしていると思いますが、当社のHR Spannerは10名程度の比較的小規模な開発であり、それを前提とした内容になっています。 DevOpsとは何か? 書籍「LeanとDevOpsの科学」では大規模アンケート調査により、高収益、高利益率、高市場占有率を持つ企業は、単に起業家精神やM&Aの取り組みだけでなく、開発組織におけるDevOpsのケイパビリティを強化している傾向が浮かび上がっています。この結果は単なる相関関係ではなく、統計手法によって因果関係として確認されています。また
"Like LeetCode for Linux" Capture The Flag challenges. Train and prove your debugging skills. Practice for your next SRE/DevOps interview. Get a full remote Linux server with a problem and fix it.
システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション 作者:Jeffery D. SmithオライリージャパンAmazon いやー刺さりまくる名言のオンパレードみたいな1冊『システム運用アンチパターン 』。 この本で最初に出てくる具体的な事例が「パターナリスト症候群」という内容なんですけど、これまでの技術書にありがちな「作業品質向上や、効率化のため」というより、組織のアジリティを下げてしまう「重い承認プロセス」を排除するために自動化しましょう、と言っているところが良い。 自動化をする理由が効率化とか、品質じゃなくて、重い承認プロセスを不要にするためである、というところが新しいし、アンチパターンに技術で立ち向かうところが、良い— magnoliak🍧 (@magnolia_k_) 2022年4月23日 なので、そもそも「承認プロセス」というのは何
lbr.より。 BY リー・ブリッグス 初めて聞いた言葉を思い出すのは、ほとんどの人にとって難しいことでしょうが、私は初めて「DevOps」という言葉を聞いた時のことを覚えています。2013年、その時点で私が知っていることのほとんどすべてを教えてくれた同僚とビールを飲んでいるときのことでした。私は幸運にも、自分が始めた新しい仕事に彼を連れてくることができました。彼は、多くの気の利いたことができ、私は彼の力に便乗することができました。私たちは、新しい会社で目にした問題のいくつかを話し合っていました。それは、おそらく今ではほとんど人にとって身近に感じられるものでしょう。アプリケーションが本番稼働しているときのサポートに苦労していたのです。 彼は、私たち全員が同じ考えを持つためには、ライフサイクルの早い段階から関与する必要があると話していました。その時、彼がオーストラリア訛りで言った「DevOp
Docker Desktopは普段使いのマシンでコンテナーでアプリケーションを実行することができるソフトウェアで、Dockerのサイトからダウンロードして使うことができます。 開発中のアプリケーションのテストとか、手元の環境でソフトウェアを動かしてみたい時に便利です。VSCodeとの連携もバッチリで、VSCodeコードでコーディングしたアプリケーションをDockerコンテナーで実行するDevContainerにも対応しています。最近のバージョンでLinux Desktop版も提供されるようになったので、もちろんパソコンは必要ですが、Linux DesktopにDocker Desktopをインストールすれば、ほぼ無料でコンテナーベースのアプリケーション開発が可能になります。 良い世の中になりました。 そんな便利なDocker Desktopですが、Dockerの方針変更で次の条件に当てはま
以下のイベントの発表資料です。 https://phpcon.php.gr.jp/2022/ 想定課題 開発がスケールしたり、開発年数が経過すると、様々な要因で開発生産性の低下が起こります。 そこで現場のエンジニアは改善をしたくなるかと思いますが、大抵の場合、ステークホルダーと工数確保の合意が必要になります。 その際にこのようなことを言われがちではないでしょうか? 今動いているものを直す必要ある? 効果測定どうやんの? 費用対効果はどれくらい? パフォーマンスチューニングの世界には「推測するな計測せよ」という言葉がありますが、開発組織における生産性についても測定してモニタリングする必要があると思います。 本セッションの目標 以上を踏まえ、本トークでは開発組織とステークホルダーの間の共通言語を獲得することを目標に以下の内容についてお話します。 State of DevOpsとは Four K
トランスクリプト Protsenko氏:私の名前はMykytaです。Netflixで働いています。私の仕事は基本的に、他の開発者が遅くまで職場に残らなくてもいいようにすることです。彼らが午後5時に退社しても生産的であることが私の実現したいことです。私はプラットフォーム組織、つまり生産性エンジニアリング部門で働いており、他のエンジニアのために労力を抽象化しようとしているのです。エンジニアが同じ退屈な技術的問題に何度も対処するのではなく、ビジネス上の問題の解決に集中できるようにします。 いくつか質問させてください。あなたたちのうち何人が、自分で作って自分で動かすという哲学を実践している会社で働いてますか?生産現場との間にゲートキーパーがいないこと、機能や修正をより早く提供できることに満足している人はどれくらいいますか?本番環境で発生したインシデントに対処しているときに、どうすればいいのか分から
世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説(後編)。DevOps Days Tokyo 2022 世界中のITエンジニアが悩まされている問題の1つに、テストが原因不明で失敗する、いわゆる「フレイキーテスト」があります。 フレイキーテストは、リトライすると成功することもあるし、失敗する原因を調べようとしてもなかなか分かりません。GoogleやFacebookやGitHub、Spotifyといった先進的な企業でさえもフレイキーテストには悩まされています。 このフレイキーテストにどう立ち向かうべきなのか、Jenkinsの作者として知られる川口耕介氏がその最新動向を伝えるセッション「Flaky test対策の最新動向」を、4月21日、22日の2日間行われたイベント「DevOps Days Tokyo 2
どうも、 もこ@札幌オフィス です。 私事とはなりますが、先日「Unicorn Rentals」というユニコーンを貸し出すスタートアップ企業に転職しまして、ユニコーンを使って初出社している最中です。 皆さんご存じの通り、世の中の車・バス・電車などの交通手段は全てユニコーンに置き換えられ、近年ユニコーンの貸し出し事業は盛んになりつつあります。 Unicorn Rentalsではビジネスの主軸となるサービスをAWS上で運用しています。 オフィスに着くと入社オリエンテーション担当の人事の方がこう言いました。 「DevOpsチームは昨日全員退職してしまった。まあ、大した人たちじゃ無かったから、君の活躍に期待してるよ」 どうやら私の仕事はDevOpsチームが残したAWS環境を改善して、負荷対策を行ったり 環境を構築したり、AWSレイヤーでトラブルシュートをしたり、チューニングをする必要があるみたいで
GitLab社は日本語で「タヌキ(Tanuki)」と命名されたロゴを使用していることがITエンジニアのあいだでしばしば話題になります。それはタヌキというユニークな名前のせいだけではなく、その外観がキツネにしか見えないからでもあります。 そのGitLabのタヌキロゴのリニューアルが4月末に行われました。下記のツイートに添付された画像の、一番左のリアルな顔が最初のタヌキ、その右の角張っているのがこれまで見慣れていたタヌキ、そして真ん中の少し丸みを帯びたものが新しいタヌキです。 In the spirit of iteration — and in celebration of the cultural shift in DevOps — our Tanuki logo is evolving to reflect our commitment to the DevOps lifecycle.h
※この記事は 開発生産性 Advent Calendar 2022 のカレンダー2の13日目の記事になります。 前回は1日目は hiroshinishio さんの 『より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標』 で、個人的には指標それぞれの分析や改善の方法が書かれていて勉強になりました。 こんにちは。 モノタロウで主に DevOps エンジニアとして活動している伊藤です。 休日はジムに節制した食事、サウナと健康を意識するおじさんとしても活動しています。 (最近だと渋谷の改良湯さんのサウナと外気浴スペースの具合が最高でととのいました) 今回は DevOps Four Keys*1 (以降 4keys と呼称) というソフトウェア開発チームのパフォーマンスを示す4つの指標を導入し、部門の目標として掲げたここ1年の取り組みを紹介できればと思います。 背景
1. はじめに システム開発にまつわるチームや組織の活動は、指標なんかで測れるわけないやろ~、という声は根強いです。ましてや、それが人の評価になろうものなら、感情的な反発さえありえます。Martin Fowlerもこちらよりです。 一方で、何らかの指標で測れるはずじゃないの?という声も根強い気がします。測れんかったら、良くなったかどうか、どうやって判断すんねん、という意見ですね。DORA Metricsを擁するGoogleはこちらよりですかね。 私はどちらなのかというと、後者で、測れるものは測りたいタイプです。もちろん、すべてが正しく測れるなどとは思っていません。そもそも定性的な指標と定量的な指標のバランスが大事であり、定量的な指標でさえも、現実世界では正確性と計測コストはトレードオフだと思ってます。 しかし、ではじゃあ、具体的にどうすればいいのか?それをまとめてみましたので、ご覧ください
はじめに 昨年、AWS のインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を紹介した記事、「【AWS】ぼくのかんがえたさいきょうの運用・監視構成」が投稿したその日の Qiita のトレンド 1 位になり、はてなブックマークのテクノロジー分野でトップを飾りました。(たくさんの方に見ていただき感謝してます!) 本記事では「ぼくのかんがえたさいきょうの運用・監視構成」の続編として「ぼくのかんがえたさいきょうの DevOps 実現構成」を紹介させていただきます。あくまでも「ぼくのかんがえた」なので私個人の意見として受け入れていただけると助かります。 前回の記事でもお伝えいたしましたが、各個人・企業によって環境は違うと思いますし、使いやすいサービスは人それぞれだと思うので、これが正解という訳ではありません。一個人の意見として参考にしてただければ幸いです。 また、こちらの記事
このブログエントリは日本信頼性学会論文誌 Vol.42, No.2, 2020年3月号に寄稿した「アジャイル/DevOps開発における品質保証と信頼性」という解説論文の転載です。 (品質管理研究会でこの解説論文の内容をもとにした特別講義を来年実施します。ご興味ある方はぜひご参加ください。) --- 概要 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps などのソフ トウェア開発手法は,今まで主流であったウォーターフォール開発と異なる特徴を持つため,その品質保 証や信頼性の考え方をそのまま適用できない場合も多い.アジャイル/DevOps 開発では短い開発サイクル の中で小刻みなフィードバックループと改善活動を繰り返しながら開発する.そのため,QA テストとして の品質保証の役割はアジャイル/DevOps においても依然重要であるが,それに加え開発サイクル
※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 DevOps Research and Assessment(DORA)チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合(%) サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができま
はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに? Four Keys とは なぜ Fo
DockerでDevOpsな環境を整える ここ数年、炎上してる案件にアサインされてる。。 傾向として、svnでブランチがいっぱい作ってマージでデグレしたり、 Excelでバグ表を管理したり、ガントチャートを手作業で管理したり、 結合テストの段階までプログラムを動かしたテストをしてない、 テストが自動化されていないと惨憺たる状況が見られる。。。 正直、付き合ってられない😭 チンパンジーを相手にしてる気分、 ということで、docker-composeを使って、進捗/バグ管理にRedmine ソース管理と自動テストのためにgitlab,gitlab-runnerの環境を整えてみました。 ソースコードやバグの管理、テストの自動化などに使っていただければ幸いです。 docker-compose.ymlファイル version: "3" volumes: # gitlab関連Volume gitla
みなさんこんにちは。@ryuzeeです。 2021年12月1日に発売した『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』ですが、おかげさまで多くの方に読んでいただき感謝しています。 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計著者/訳者:マシュー・スケルトン、 マニュエル・パイス、 原田 騎郎、 永瀬 美穂、 吉羽 龍太郎出版社:日本能率協会マネジメントセンター発売日:2021-12-01単行本:280ページISBN-13:9784820729631ASIN:4820729632 今日はこの「チームトポロジー」の元となったDevOpsトポロジーについて紹介します。 このアイデアは2013年に著者の1人であるマシュー・スケルトンが自身のブログに書いた記事をまとめたものです。 2013年頃といえばDevOpsが流行しはじめた時期だと思いますが、こ
ここで話すこと ここで話さないこと SRE/DevOps/Kubernetesをテーマにブログを書き始めた理由 気をつけていること オススメWebページ7選 The Blameless Blog Netflix Technology Blog Facebook Engineering Datadog blog The GitHub Blog Julia Evans The Kubernetes Podcast from Google ブログによる変化 反響 やってみて思ったこと 異動による変化(2020年4月) コミュニティー活動による変化 今後の目標&告知 これは エーピーコミュニケーションズ Advent Calendar 2020 の20日目の記事です。 自身の中で多くの変化があった2020年をふりかえりつつ、タイトルにあるテーマ(SRE/DevOps/Kubernetes)を追いか
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。DevOpsは「開発担当者と運用担当者が密に連携することで、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に紐解きながら、DevOpsの考え方をご紹介します。また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどをDevOpsを実践する3社の事例を交えて解説します。 「DevOps」とは
小西秀和です。 この記事は「AWS認定全冠を維持し続ける理由と全取得までの学習方法・資格の難易度まとめ」で説明した学習方法を「AWS 認定 DevOps エンジニア – プロフェッショナル(AWS Certified DevOps Engineer – Professional)」に特化した形で紹介するものです。 重複する内容については省略していますので、併せて元記事も御覧ください。 また、現在投稿済の各AWS認定に特化した記事へのリンクを以下に掲載しましたので興味のあるAWS認定があれば読んでみてください。 ALL Networking Security Database Analytics ML SAP on AWS Alexa DevOps Developer SysOps SA Pro SA Associate Cloud Practitioner 「AWS 認定 DevOps エ
はじめに こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity(開発生産性)が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。 私の所属する株式会社カカクコムの食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]!
リリースから12年を迎えた「Chatwork」は、国内ビジネスチャットのフロントランナーとして、中小企業を中心に41万社以上の企業・組織に利用されています(2023年6月時点)。DAU(デイリーアクティブユーザー)も100万を超えるため(108.6万、2023年6月時点)、ビジネスタイムには絶えず飛び交う大量のメッセージをサービスとして安定して処理することが求められます。 一方で、長期間の開発によって蓄積した技術的負債等に対応するため、システムのアーキテクチャを見直す時期にもあります。それにあわせて開発組織も、巨大なモノリスに対して案件ごとにプロジェクトを組み直す既存の体制から、職能を横断したチームが自律して開発を推進できるフィーチャーチームへの移行がまさに進行しています。 こうした開発改善の実情と進め方について、本部長として推進する田中佑樹さん、エンジニアとしてフィーチャーチームに所属す
以前からAmazonの欲しいものリストにはあったのですが、なかなか読みたい気持ちにならずリストを整理するときに削除しちゃっていたのですが 2月ぐらいからTwitterでこの本についての言及が増えたし、ちょうどそのころ開発生産性とは何か、について一考していたこともあったので、読んでみました。 LeanとDevOpsの科学 一旦さらっと読んで、面白いなー、やっぱデリバリ大事だなーと思って読了したんですが 先日texta.fmでこの本のことが取り上げられており、あー、そんな読み方があったかーと思って改めてちゃんと読み直してみました。 構成 第一部: 調査結果から見えてきたもの(パフォーマンスを向上させるケイパビリティとは何かの話。特にデリバリを中心に多面的に検討している) 第二部: 調査・分析方法 第三部: 改善努力の実際(いろんな会社の取り組みの事例) 読み方 常に付録Aの図A.1を開いてお
今や生産性の可視化・評価指標といえば本書籍で紹介された『FourKeys』ですね。ちまたでは、絶対視されている様な表現・評価がされている記述をたまに見かけます。ですが、本当にそうでしょうか?ある方が調べたところ、FourKeys を使用している人のうち『Lean と DevOps の科学』を読んだことがない人は9割近くもいたそうです。 本記事では、FourKeys を有効に活用するために知っておくべき・理解しておくべき事柄を幅広い分野でまとめました。生産性を向上し、仕事の成果の質を上げたいと努力するエンジニアの方々が、次の日から使える情報を書けたのではないかと思います。FourKeys だけを見て生産性を上げるという行動は手段の目的化につながりかねません。Fourkeys の背景にある思想を知ることで、FourKeys を真に活用するきっかけになればと思います。 目次 初めに GW中に読も
いまさらですが、DevOpsとは何か、具体的には何に取り組むべきなのかについて整理しました。DevOpsとは、サービスの継続的な改善を実現するために、Dev自身がサービスの運用ができるよう、Opsは運用作業のツール化を進めていく取り組みです。そして、DevOpsエンジニアやSREなど、新たな役割への転換が求められます。 DevOps = 開発と運用の協業? Velocity 2009というイベントで、写真共有サイトFlickrのエンジニアJohn Allspaw氏とPaul Hammon氏が「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」( ビデオ / スライド )という講演を行います。この講演ではWebサービスの運用における開発チームと運用チームの協業が語られています。両者が同じ目線に立つためにツールを活用するとともに、カル
Kubernetesが標準プラットフォームであるクラウドネイティブの世界でアプリケーションを開発し運用する方法を解説する書籍です。 はじめに、Kubernetesの概要と背景、ソフトウェアの開発と運用にKubernetesがもたらす変化、コンテナの動作原理、コンテナの構築および管理方法、クラウドネイティブなサービスおよびインフラの設計方法などの基礎を紹介します。 そしてKubernetesアプリケーションの作成とデプロイ、Kubernetesクラスタの設定と運用、クラウドインフラの自動化、Helmなどのツールを用いたデプロイについてサンプルコードを使って学習します。ロールベースのアクセス制御(RBAC)をはじめとした、セキュリティ、認証、パーミッションなどに対するKubernetesのサポートや、本番でコンテナとKubernetesの安全性を確保するためのベストプラクティスについても学びま
本連載では、スピードと品質を両立するためのアジャイルテスティングにおける重要なキーワードである「テストの自動化」について、WebブラウザやAPIレベルのエンドツーエンドテスト(E2Eテスト、この連載でのテスト自動化は主にE2Eテストの自動化を指しています)が求められる時代背景から、戦略や戦術、組織づくり、ノーコード・SaaS型のAIを活用したテスト自動化サービスの進化と具体的な実装、ベストプラクティスを解説します。第1回は、アジャイル開発やDevOpsが当たり前になった時代において求められるテストや品質について、時代背景を追っていきます。 はじめに 技術の進化とともに開発スピードは格段に上がり、システムはより複雑になり、求められる品質も高まっています。アジャイル開発やDevOpsという言葉が一般的になった今、これまで幾度となく議論されてきた「スピードと品質」の問題は、トレードオフではなく、
Professional Cloud DevOps Engineer は SRE を目指すエンジニアにお勧めしたい資格でした 本記事は 2021/07/06 時点の情報になります。そのため時期によって異なる情報になる可能性があります。ご留意の上、お読みください。 はじめに こんにちは、 CX事業本部 MAD事業部 の 田中孝明 です。 つい先日、 Google Cloud 認定資格 の Professional Cloud DevOps Engineer を苦労の末合格しました。 試験の内容に関しては NDA になるため記載することはできませが、勉強した内容をお伝えすることで、挑戦する方の励みになるような記事になればと思い公開いたします。 Professional Cloud DevOps Engineer について Professional Cloud DevOps Engineer は
AWS Well-Architected フレームワーク DevOps ガイダンスが発表されました。 ガイダンスは6つの柱とは違い、特定のユースケースやテクノロジーにフォーカスしたドキュメントです。DevOps を継続的かつ効果的に導入・実践することを支援してくれます。 ベストプラクティス〜アンチパターン〜メトリクスという段落構成になっており、ありがちな理想論を語るドキュメントではなく本当に実践的です。 それでは DevOps ガイダンスをサマってみます。本エントリは機械翻訳でサマっています。ご了承ください。 本家のドキュメントはこちらです。ぜひお読みになってください。 DevOps Guidance 要約と紹介 最初の章です。このガイダンスを作成するに至った経緯や言葉の定義が書かれています。 面白い一文があったので引用します。 There is no one-size-fits-all
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く