野良社内ツールと開発生産性、プラットフォーム・エンジニアリング - Runner in the High
よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。 たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々が手でやっている作業が有志で自動化されツールになるなど。そして社内の口コミや告知で伝搬され、使われていく。 出来の良い社内ツールは、野良だとしても開発チームが普段の開発プロセスのなかで意識したくない複雑性や実装の詳細をうまく抽象化し、認知負荷を下げる役割を果たしている。見方を変えれば、社内ツールはチーム・トポロジー*1でいうところのX-as-a-serviceインタラクション・モードの具象化のひとつだと言える。開発チームと社内ツールを開発する人間を社内ツールがインターフェイスとなって接続している。広い目線で見ると、これはプラットフォーム・エンジニア
DevOpsは失敗する
lbr.より。 BY リー・ブリッグス 初めて聞いた言葉を思い出すのは、ほとんどの人にとって難しいことでしょうが、私は初めて「DevOps」という言葉を聞いた時のことを覚えています。2013年、その時点で私が知っていることのほとんどすべてを教えてくれた同僚とビールを飲んでいるときのことでした。私は幸運にも、自分が始めた新しい仕事に彼を連れてくることができました。彼は、多くの気の利いたことができ、私は彼の力に便乗することができました。私たちは、新しい会社で目にした問題のいくつかを話し合っていました。それは、おそらく今ではほとんど人にとって身近に感じられるものでしょう。アプリケーションが本番稼働しているときのサポートに苦労していたのです。 彼は、私たち全員が同じ考えを持つためには、ライフサイクルの早い段階から関与する必要があると話していました。その時、彼がオーストラリア訛りで言った「DevOp
アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~ - Test Automation
はじめに こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity（開発生産性）が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。 私の所属する株式会社カカクコムの食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]！
Infrastructure as Code の静的テスト戦略 #DevOpsDaysTokyo / DevOpsDays Tokyo 2021
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか？ 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。 ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。 しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしま
CTO不在の企業で開発組織を作っていくために大事なこと｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 これは CTOA Advent Calendar 2020 の5日目の記事です。 今までウノウとUUUMの2社のスタートアップでCTOを足掛け10年近くやってきました。経歴柄、CTOのいない企業から開発組織の作り方の相談を受けることが多いですが、やはりCTOが不在で開発組織を作っていくのは非常に困難です。とはいえ、転職市場に都合よく即戦力になりうるCTO人材が簡単に見つかるのも稀です。そこでCTOが不在の中で開発組織を作っていくために大事なことをまとめてみました。 開発組織作りで大事なのは採用ではなく環境作り開発組織作りで大事なことはいろいろありますが、最も大事なのは採用と環境の2つではないかと思います。環境が良くなければ優秀なエンジニアは採用できないし、優秀なエンジニアに来てもらえなければ良い開発環境を作ることができません。いわゆる
無料＆オープンソースでシステム障害のレポートを一元化できるNetflix製インシデント管理ツール「Dispatch」
システムの保守・運用を行うインフラエンジニアにとって、障害対応は最も責任のある仕事のひとつであり、障害の監視や通知に関するツールは「PagerDuty」や「Zabbix」が有名です。そうした障害対応を助けてくれるツールとして、Netflixが無料のオープンソースソフトウェア「Dispatch」を公開しました。 Introducing Dispatch - Netflix TechBlog https://netflixtechblog.com/introducing-dispatch-da4b8a2a8072 About - Dispatch https://hawkins.gitbook.io/dispatch/ Netflix Dispatch - Reviews, Pros & Cons | Companies using Netflix Dispatch https://stack
インシデント指揮官トレーニングの手引き | Yakst
[SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。
CI/CDの原則とデザインパターン (整理会)/20190722-jaws-ug-arch-pipeline-principle
2019年7月22日のJAWS-UG アーキテクチャ専門支部での発表資料です。 引き続き、議論・更新していきたいと思います。 (運用設計ラボ合同会社 波田野裕一)
DevOps時代のアーキテクチャ品質特性とプロセス品質概論 - Test Automation
はじめに DevOpsという言葉は2008年に誕生した。その概念は2015年頃日本でも再注目され、これまでDevOpsに有用な技術や文化の変革について議論されてきた。このブログエントリでは、DevOpsがアーキテクチャとプロセスに与えた影響についておさらいしたのち、DevOpsに必要なアーキテクチャの品質特性とプロセス品質を一覧で示す。 DevOpsがアーキテクチャとプロセスに与えた影響 DevOpsの意義 プロダクト開発では、要求分析からリリースまでのサイクルを回し顧客からフィードバックを素早く得ることで、プロダクトの品質を素早く継続的に向上することが重要だ。これを達成するため、「要求分析」「設計」「実装」「テスト」「リリース」などのバリューストリームマップに含まれる工程の生産性を改善し、リードタイムを短縮する手段を、DevOpsは提供する。下記の図で黄色の線で示された、要求分析からリリ
オブザーバビリティ（可観測性）がなぜ必要だと考えるのか - YAMAGUCHI::weblog
はじめに こんにちは、Stackdriver担当者です。本記事は完全に個人の意見です。（念押し） GCP的に担当製品がわかりやすいのでStackdriverの担当と書いてますが、仕事での担当領域的には「オブザーバビリティ (Observability、可観測性)」 です。この「オブザーバビリティ」という言葉が近年SREの文脈で語られることが増え、また今年に入って「入門 監視 ("Practical Monitoring" の日本語訳)」が刊行されたことで、日本でもより多く耳にするようになりました。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 発売日: 2017/08/12メディア: 単行本（ソフトカバー） 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julian発売日: 2019/01/17メディア:
The 2019 DevOps RoadMap | POSTD
DevOpsエンジニアになるためのイラストガイド（関連コースへのリンク付き） DevOpsは今とてもホットなテーマです。多くの友人、同僚、上級開発者である知人がDevOpsのエンジニアとなり自分のいる組織の中で第一人者になろうと一生懸命になっています。 私は DevOps の恩恵を心から認めています。DevOpsはソフトウェア開発とデプロイの改善に直結しているからです。しかし私の限られた経験から言っても、DevOpsのエンジニアになるのは 簡単ではありません。 非常に多くのツールと事例があり、適切な学び方を選ぶのがとても難しいのです。 Javaのブロガー としてよく質問を受けます。例えば、 DevOpsのエンジニアになるにはどうすれば？ どのツールを学べば？ どんな事例を参考にすれば？ DevOpsエンジニアにはMavenとJenkinsがマストですか？ DockerやKubernetes
DevOps的な非機能要件（運用要件）リスト - 勘と経験と読経
The DevOps Handbookで紹介されていた The Top Ten DevOps “Operational Requirements” | DevOpsGroup を読んだら面白かったというメモ。国内ではあんまり取り上げられていないような気もする（もしくは私が不勉強で知らないだけ？） The DevOps ハンドブック 理論・原則・実践のすべて 作者: ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス出版社/メーカー: 日経BP社発売日: 2017/07/04メディア: Kindle版この商品を含むブログを見る 開発部門が下流の作業の状況をフォローし、本番インシデントの解決の作業に参加すれば、アプリケーションは次第に運用にとってよい設計になっていく。さらに、スピーディなフリーとデプロイのしやすさを正面から意識してコードやアプリケーションを設計するようになると、
第1回：いま、運用をデザインできる人材が求められている | システム管理者の会ポータルサイト
目指せ、運用デザイナー！～システム管理者の明日を考える 第1回：いま、運用をデザインできる人材が求められている 開発と運用の壁。これがさまざまな問題を生む。開発担当者は運用を考えずにシステムをリリースし、足りない部分は｢運用でカバー｣の一言で運用担当者にナントカさせようとする。そして、たいてい火を吹く。なぜなら、リリース間際に対処しようとしても付け焼き刃の属人的な対応しかできないからだ。この状況、運用も開発も、何よりシステムを使う顧客やユーザも幸せにしない。運用をデザインしよう。この連載では、運用を主体的にデザインし、価値あるITサービスを提供できる人材になるための視点や行動を考えます。 目次 運用設計の不在が生む悲劇 ｢開発｣と｢運用｣が分断。そして、運用設計が抜け落ちる 運用をデザインする。そのための6つのポイント 開発と運用の壁。これがさまざまな問題を生む。開発担当者は運用を考えずに
AWSネットワーク構成図の手動更新が辛い？よろしい、ならばCloudMapperだ
株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOSというサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。 今回は、入社してから半年経ったらいつのまにかサービスのネットワーク管理者になっていて、そこで発生した問題と、それを解決するのに非常に役立ったCloudMapperというOSSを紹介したいと思います。 発生した問題 私がネットワーク管理者を引き継いだ段階では、ネットワーク構成図が作成されておらず、以下の問題が発生していました。 ロードバランサーを止められない 用途不明のロードバランサーが存在したため、停止を検討した。 しかし、どのリソースから利用されているか見えず、不用意に停止できなかった。 用途不明なEC2インスタンスの調査ができない AWSからメンテナンス通知が来た対象が用途不明なEC2
その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 /20180712-janog42
2018年7月12日、三重県津市で開催のJANOG42ミーティングでの発表資料です。 その運用自動化では行き詰まる 〜「つながらない」「つたわらない」「つみあがらない」を防ぐために〜 https://www.janog.gr.jp/meeting/janog42/program/OPE 詳細: https://www.opslab.jp/publish/20180712-janog42.html 以下の方々と議論し、多くの知見を得ることができました。(敬称略) - 長久 勝 (国立情報学研究所) - 今井 祐二 (株式会社富士通研究所) - 畠山 慎平 (エヌ・ティ・ティ・コミュニケーションズ株式会社) (運用設計ラボ合同会社 波田野裕一)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Terraform Module Designs
【SRE Next 2020】発表資料まとめ - Qiita
The DevOps に見る戦略ピラミッドと残念なITIL | itSMF Japan White Paper
効果的なアーキテクチャレビューボードを構築する
最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck
