SRE_Culture_Organization
Infra Study Meetup #3 「SREのこれまでとこれから」の発表資料です https://forkwell.connpass.com/event/176885/
Infra Study Meetup #3 「SREのこれまでとこれから」の発表資料です https://forkwell.connpass.com/event/176885/
Zero Touch Productionとは何か
GoogleのSREとSecurityによるBuilding Secure Reliable Systems という本の中で「Zero Touch Production (ZTP) 」という考え方が紹介されていた．これはインフラの権限管理やインフラの構築そのものの指針となる概念であり，自分がそうあるべきだとずっと思ってきた考え方でもある．これはどのような考え方なのか?をこれまでの歴史を踏まえて具体的なツールや事例とともにまとめておく． Zero Touch Production Building Secure Reliable Systems においてZero Touch Production (ZTP) は以下のように定義されている． The SRE organization at Google is working to build upon the concept of least
第1回 Platform Engineering Meetupで発表した資料です。 #PFEM
Google Cloud Platform (Google App Engine, Compute Engine, BigQuery や Container Engine など）の情報の日本公式ブログ
現在 estie では、デプロイの改善・統一に取り組んでいます。複数プロダクトのそれぞれの技術スタックが大きく違う中、どう考えたら効率的なデプロイを組めるのか。2024年のデプロイの原則について、あらためて考えてみました。
システム監視、何からはじめる？ / What is the first step for system monitoring?
2020/08/31開催の、Infra Study Meetup #5「企業に必要とされているインフラ技術とこれから」のLTでお話した内容です。 https://forkwell.connpass.com/event/183909/
100人規模のエンジニア組織で DevOps Four Keys を導入し、アジリティー向上を目指した取り組み - MonotaRO Tech Blog
※この記事は 開発生産性 Advent Calendar 2022 のカレンダー2の13日目の記事になります。 前回は1日目は hiroshinishio さんの 『より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標』 で、個人的には指標それぞれの分析や改善の方法が書かれていて勉強になりました。 こんにちは。 モノタロウで主に DevOps エンジニアとして活動している伊藤です。 休日はジムに節制した食事、サウナと健康を意識するおじさんとしても活動しています。 （最近だと渋谷の改良湯さんのサウナと外気浴スペースの具合が最高でととのいました） 今回は DevOps Four Keys*1 （以降 4keys と呼称） というソフトウェア開発チームのパフォーマンスを示す4つの指標を導入し、部門の目標として掲げたここ1年の取り組みを紹介できればと思います。 背景
CI/CD方針、テスト・QA方針と連動する三分類ブランチ管理方針で、開発での高品質と高スピードの両立を支える - 千里霧中
最近の開発では、CI/CD、自動テスト、継続的テストが当たり前となっていますが、その影響で、それらのCI/CD方針、テスト方針と、Git等のバージョン管理のブランチ方針をどう連携させるかが、定番の課題になっていると感じています。 今回は、このブランチ方針、CI/CD方針、テスト方針を連携させて、開発の品質とスピードを向上させるアプローチについて解説します。 結論から言うと、要点は以下の二つとなります。 バージョン管理のブランチ方針は、CI/CD方針、テスト・QA方針と不可分であり、連携を考えながら方針立てする必要がある ブランチ方針の工夫で、CI/CD、テスト・QAの開発インフラリソース消費を削減でき、本当に重要なポイントに開発インフラリソースを投入できる。これにより、限られたリソースでの高品質・高スピードの両立を支えられる 背景：開発インフラの進化が全てを解決すると楽観視していた発展期
株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOSというサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。 今回は、入社してから半年経ったらいつのまにかサービスのネットワーク管理者になっていて、そこで発生した問題と、それを解決するのに非常に役立ったCloudMapperというOSSを紹介したいと思います。 発生した問題 私がネットワーク管理者を引き継いだ段階では、ネットワーク構成図が作成されておらず、以下の問題が発生していました。 ロードバランサーを止められない 用途不明のロードバランサーが存在したため、停止を検討した。 しかし、どのリソースから利用されているか見えず、不用意に停止できなかった。 用途不明なEC2インスタンスの調査ができない AWSからメンテナンス通知が来た対象が用途不明なEC2
新規事業を加速させるリサーチ術/ Research tips for new biz creation
ビザスクさんにお誘いいただき、企業内新規事業担当者の方などに向けて、リサーチに関するお話をしました。 https://visasq.co.jp/seminar/research0728 調査、正しく使うと楽しいし、ためになるよ、というお話をしています。 30分くらいでお話したので、同じような講演ニーズがあればぜひまたお知らせください :-) info@cobe.work
AWS IAM セキュア化の取り組み
鍵がいっぱいあるよこの記事は Eureka Advent Calendar 2021 の 13日目の記事です。 はじめにこんにちは、エウレカ SREチーム のハラダです！ 2020年頃から今年にかけて、 エウレカのSREチームとSecurityチームではAWS IAMのセキュア化を注力ポイントのひとつとして、継続的に取り組んできました。 本記事では、その実践から学んできたIAM管理で守るべき大原則および、具体的にどうやってセキュアな理想像に近づけてきたか、今後の方向性などを話したいと思います。 Why “IAM” so important ?そもそもなんでIAMが注力ポイントなの？と疑問に思われる方もいるでしょう。 クラウドの大きな強みである「すべてをAPI経由で操作できる」という性質ゆえに、IAMは大きなAttack Surfaceでもあります。 Gartner社の予測によると、2023
信頼性目標とシステムアーキテクチャー / Reliability Objective and System Architecture
SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17
8. データのフォーマット • 大量の収集を行うためにメトリックスのフォーマット は標準化されている必要がある • key/value式のプレーンテキストを返す • スキーマ―を持たないテキストベースのインターフェ イスが追加の障壁を低くする go_gc_duration_seconds{quantile="0"} 8.007600000000001e-05 go_gc_duration_seconds{quantile="0.25"} 0.000297585 go_gc_duration_seconds{quantile="0.5"} 0.00030774400000000004 go_gc_duration_seconds{quantile="0.75"} 0.000317933 go_gc_duration_seconds{quantile="1"} 0.00449756600000
継続的なソフトウェア・アップデートのためのDevOpsベストプラクティス・アンチパターン / DevOps Patterns and Antipatterns for Continuous Software Updates
Cloud Native Days Tokyo 2020
はじめに 小室です。2017年も最後の日になりました。 ここ最近は読書によるインプットが少なくなったことによって、文章の質が自ら目を背けたくなる程度に低下していたため、仕事納めから数日はひたすら本を読む生活をしていました。まだまだインプットが足りていないので充電が完了していないのですが、年末恒例になったエントリーを書かないことが自分の中でモヤモヤとして残っていたので、重い腰を上げて文章を書いてみようと思います。 ここ数年は珍しく1つのプロジェクトにつきっきりで設計／実装から運用までを通して担当しています。 *1特に運用を担当するようになって多くを学んだ一年でした。もはや設計・実装者が一人も残っていないアプリケーションのメンテナンス、改修に関わったり、インフラ側とアプリケーション側の狭間を埋めるように動くためにAWSのサービスについて本格的に勉強をしたりするなど、1アプリケーションエンジニア
レスポンシブWEBデザインのデザイン・設計上の注意点 | Web制作 | | SRE BLOG | SRE BLOG
レスポンシブWEBデザインはその特徴から、レイアウトの自由度が低いと言われています。どのようなデザインにするのかは悩ましい問題とも言えるでしょう。 そこで今回は前回のレスポンシブWEBデザインの基本に続き、実際の事例とともにデザインや設計における注意点を紹介していきます。 １、各デバイスのサイズを把握しましょう！ レスポンシブWEBデザインの最大の特徴はなんと言っても、色々な端末から見れるということ。設計する前に端末のサイズを把握していなければ、始まりません。 参考までに主要なディスプレイサイズを図にしてみました。 ユーザーがいつどんな環境でサイトを見るのか、考えてみることが大切ですね。 ２、よく使うブレークポイントはこれだ！ どの画面サイズでも見やすいサイトになるよう適切なブレークポイントを設定しましょう。 ちなみにSRE BLOGでは1160,1080,1024,985,960,940
Renovate の大量の Pull Request を処理する技術 - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform Monorepo に対する Renovate の大量の Pull Request を処理するための技術について紹介します。 背景 過去ブログで何度か紹介しているように、弊プロダクトでは Terraform の Monorepo を管理しています。 先日、 CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました。 blog.studysapuri.jp working directory (state) の数は 400 近くあり、 working directory ごとに以下のような tool のバージョンを管理しています。 Terraform Terraform Provider tflint tflint plugin tfsec etc これ
Gravitational 「teleport」「teleconsole」など、クラウドネイティブのアプリケーションとインフラストラクチャを提供するオープンソースソフトウェアベンダー この記事は、著者の許可を得て配信しています。 https://gravitational.com/blog/solid-infrastructure-security-without-slowing-down-developers/ この記事では、SaaS企業が強固なクラウド・インフラストラクチャ・セキュリティを持つことと、やりすぎて自社のエンジニアを怒らせてしまうことのトレードオフにどのようにアプローチしているかについて、私の見解を共有したいと思います。 セキュリティというものはイライラの原因になります。セキュリティがイライラの原因にならなければ、日々の暮らしがもっと楽になるかもしれません。もしあなたがSR
「NoOps」の時代がこない理由
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます こんにちは。真壁徹と申します。とあるイベントでインフラ技術者への愛を語ったことがきっかけで、この連載のお話をいただきました。 インフラ技術者はいま、向かい風を受けています。ハードウェアのコモディティ化が進み、設備投資は縮小傾向です。設備が減れば、担当する組織全体の予算も減りがちです。また、パブリッククラウドの浸透が「NoOps」につながる、と主張する人もいます。下を向いてしまいがちな状況です。 ですが、能力や意欲のあるインフラ技術者にとっては、むしろ活躍の場が広がっていると考えています。それをお伝えしたく、この連載オファーを受けました。 わたしは日系システムインテグレーターでのアプリ開発でキャリアをスタートしました。その後、外資系でイン
[SRE]原文 An Incident Command Training Handbook – Dan Slimmon (English) 原文著者 Dan Slimmon 原文公開日 2019-06-24 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket 原著者への翻訳報告 1723日前 Twitterで報告済み 編集 私が Hashicorp で担った最初の仕事のひとつは、社内向けのインシデント指揮官のトレーニング資料を作ることでした。 これは私自身がインシデントへの対処にあたりながら何年ものあいだ肌身に感じてきた、あらゆる類の考えをまとめ上げる良い機会となり、最高に面白いタスクでした。 以下は私の書いたトレーニング資料、ほぼそのままです。 あなたがインシデントレスポンスのポリシーを定義するにせよ、即興でインシデントレスポンスを行うにせよ、お役に立てたら幸いです。
どのようなシステムもそれを作るのも運用するのも人であり（SREが目指すのが運用をなくすことだとしても）、大抵の場合、一人ではなく組織としてシステムを作っていますが、信頼性の低い組織からは信頼性の高いシステムは生まれることは考えにくいです。 SRE NEXT 2022で提起した組織に対してSREを適用することでどうやって信頼性を保つことができるかということについて、実際に組織に起きた問題とそれにどういうプラクティスを適用し、どうなったのかを紹介します。
SLOを活用した技術的改善
株式会社タイミーではスキマバイトプラットフォームを開発・運用しています。サービスもリリースして3年を超え、"負債"と呼ばれるものが増えてきました。一方でビジネス的に開発したいものは後を絶ちません。そこで開発チームでSLOを制定し、サービスの健全な状態を測定・監視することで「システムが健全にサービス提供できているか」を調べ、必要なときに必要な改修を行えるようにしました。本セッションでは弊社のSLOの解釈や利用方法を伝えるとともに、実際に感じたメリットや行われた技術的改善を紹介します。 セッション動画 https://www.youtube.com/watch?v=VburNEFcg64
Don't Use Kubernetes, Yet
Early-stage startups shouldn't run on Kubernetes yet. But eventually, growth-stage and large companies should be running on Kubernetes in some form. Kubernetes Maximalism doesn't mean one-size-fits-all. Infrastructure should progressively grow with your workloads and team. How can you choose the right technology now so that you can maximize growth and minimize pain later when you inevitably outgro
「マンガが快適に読める」を数値化し、SLOをマンガビューワに導入するまで - Hatena Developer Blog
マンガビューワにおけるサービスレベルとは なぜSLOを策定したかったのか サービスレベルを単純に決める 何をサービスレベル指標としてどう計測するか 一般的なSLIの表現 期間を移動しながら集計する アクセスログからサーバーのSLIを計測する PageSpeed Insights APIでフロントエンドを計測 プロダクトオーナーとともにSLOを決定する 決定したSLO どのように監視するか まとめ 株式会社はてなのマンガチームでSREをしているhappy_siroです。 私がチームで担当しているサービスは、いくつかのWebマンガサイトで採用されている「GigaViewer」というマンガビューワです。 GigaViewerチームでは、サービスのSLOを策定しました。 理由は、SLOに基づいて開発速度と信頼性のバランスをとるためです。 この記事では、私がチームメンバーと協力して「GigaView
デプロイ今昔物語 〜CGIからサーバーレスまで〜 / The deployment technics
YAPC::Kyoto 2023
複数AWSアカウントのインフラを同じコードで Terraform管理するプラクティス - ANDPAD Tech Blog
こんにちは！ アンドパッドSREの 宜野座 です。 前回は AWSのアカウント運用改善の取り組みについて記事を書かせていただきました。 今回はアンドパッドでIacへの取り組みとして行っているものの一例として、複数アカウント・複数環境を同一コードでTerraform管理するプラクティスを紹介したいと思います。 少し長くなりますが、お読みいただけると幸いです。 前回ブログ記事 tech.andpad.co.jp なぜIaC(Infrastructure as Code)に取り組んでいるのか Terraformを選んだ理由 同一コードでTerraformを複数アカウント・複数環境へplan, applyしたい terraform init terraform plan terraform apply 環境を増やしたい場合 環境ごとにリソースを作成したり、作成しないようにしたい 他の方法に関して
はじめまして。TVerでモニタリング・オブザーバビリティ周りを担当している加我です。 この度TVerのTech Blogをスタートすることになりました！ テックブログ開設の経緯 昨年の4月にTVer Technologies社がTVer社に合流し、エンジニアリソースが拡張して開発範囲が増えたことで、新たにTVerとしてのテックブログを開設しようというのが経緯です。 tver.co.jp 今後はこちらの方で記事を公開していくことになりますが、これまで私達がどのような事をしてきたのかに関してはTVer Technologiesのテックブログも御覧ください。 TVer Technologiesのテックブログはこちら techblog.tver-tech.co.jp どんな感じにしていきたいか 今後テックブログでは私達がサービス開発を進める上で発生する課題をどのように解決しているのか、どのような技
｜DMM inside
アプリチーム x SRE チームによるアプリケーションモニタリング運用改善 - freee Developers Hub
freee人事労務の品質改善を専任で活動している keik です。 freeeではアプリケーションパフォーマンスモニタリング（APM）に Datadog を利用しています。 SRE チームが導入し、アプリケーション開発チームに利用提供する形で運用されています。 導入のきっかけについては以下の記事でも触れられています。 developers.freee.co.jp Datadog APM の画面は多機能かつ柔軟で、例えばウェブサーバーが受けたリクエスト処理の内訳を視覚的にドリルダウンできたり、リクエストや SQL クエリごとのレイテンシやエラー率を計測してダッシュボード化してくれたり、また全画面で共通的に「タグ」や日時を用いたフィルタリングができたりします。直感的なだけなく、見た目もオシャレで、適当に眺めているだけでもワクワクします。 しかし、私達は「ここに映っているもの」が何なのか、正直分
はじめに こんにちは、DevOps支援室のかたいなかです。 今回は、株式会社はてなさんの京都オフィスに伺い、はてなさんのDevOpsに対する取り組みや考え方についてガッツリインタビューしてきました！ はてな紹介 どのようなサービスをやっている 「はてなブックマーク」「はてなブログ」などのソーシャルサービスや、サーバ監視SaaSである「Mackerel」などを開発・提供しています。また任天堂様やKADOKAWA様との共同開発や、集英社様、講談社様などが運営されているWebマンガサービスへのビューワ提供にも取り組んでいます。 担当者の方の仕事内容 具体的にどのような仕事をしているのか motemenさん CTO 技術的な方針策定、エンジニア組織マネジメント。技術的な知見をどうチーム間で共有していくのか、とか、プロダクトの技術的な基準とか。評価設計と運用とか。採用とか。 ログイン、人力検索はてな
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog インフラエンジニア見習いの森本です。これまで数年ほどサーバーサイドエンジニアとして開発ばかりをしてきた人が最近インフラエンジニアになりました。 3月末に開催された Go Conference 2017 Spring で開発チームの後藤から弊社で開発・運用している AWS S3 互換の分散オブジェクトストレージ Dragon についての発表がありました。 Goでヤフーの分散オブジェクトストレージを作った話 私は Dragon の運用を担うチームに所属しており、本稿ではその業務の中で発生したトラブルシューティングについて紹介したいと思います。 分散オブジェクトストレージ Dragon で発生していた課題 Dragon で gorout
登壇資料 SRE立ち上げてどうなった？最新のコア技術とSRE事情 Lunch LT https://findy.connpass.com/event/305677/ ハッシュタグ ：#SRE_findy
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができま
RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL 2（MySQL 5.7 互換）を使っています（以下 Aurora MySQL と略します）。 ある日、社内の Slack で「𠮷」などの文字列が登録できないのではないかという話が出ました。これを聞いて「あー」と思った方も多いでしょう。 MySQL で有名な UTF-8 の 4 バイト文字問題で、歴史的な理由から MySQL 5.7 以前では utf8 の文字セットは utf8mb4 ではなく utf8mb3 を指しています。 dev.mysql.com カミナシのアプリケーションは 4 バイトの文字列が入力された場合はシステムエラーを返す実装になっていますが、エラーの内容をユーザーにわかりやすく伝えることは難しいためユーザー体験としても良くない
はじめに まず、はじめに皆さんへ言っておきたいことがあります。 このドキュメントの目的は皆さんをやる気にさせて一心不乱にコードを書きまくって新機能追加や改善をしてソフトウェアを開発していってほしいというわけではないということです。 もちろん、そうなってくれれば嬉しいですが気合が入ったからプログラムを急に書けるようになるわけではないのでそのような目的は一切ありません。また、この文章にはインフラエンジニアがコードを読み書きできなくて良いという意図はなくポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。 SREはそもそも、コードを書かなくてもよいエンジニアではない SREとは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームや役割を指します。 Google では、SREチームの50～
運用技術者組織の設計と運用 / Design and operation of operational engineer organization
第12回 インターネットと運用技術シンポジウム（IOTS 2019）～運用管理する人”も”報われるシステムの構築を考える～ にて招待講演を行った際の資料です。 概要: https://www.iot.ipsj.or.jp/symposium/iots2019/ プログラム: https://www.iot.ipsj.or.jp/symposium/iots2019-program/
https://sre-lounge.connpass.com/event/227250/
一休.com サイトパフォーマンス改善 - 2023年 夏の振り返り - 一休.com Developers Blog
ヤフー株式会社より出向しております、卯田と申します。 主務で、一休.comおよびYahoo!トラベルのフロントエンド開発を担当しています。 兼務で、ヤフー株式会社の全社横断組織でWebパフォーマンス改善の推進を行っております。 本稿では、直近半年弱(2023年2月〜8月)で、断続的に行っていた一休.comのパフォーマンス改善について振り返ります。 開始が2023年2月となった理由は、Nuxt3バージョンアップ以降にパフォーマンス改善活動に着手したためです。 一休.com/Yahoo!トラベルのNuxt3バージョンアップ詳細については、以下のブログをご覧ください。 user-first.ikyu.co.jp サイトパフォーマンス改善の意義 改善の方針 方針1: Core Web Vitalsを改善する 方針2: 重要課題から優先的に対応する 改善の進め方 可視化 ブラウザサイド サーバーサイ
はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに？ Four Keys とは なぜ Fo
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Platform Engineeringへの招待
自業自得の DDoS 攻撃から身を守るには : CRE が現場で学んだこと
デプロイ再考2024/reconsidering-deploy-in-2024
AWSネットワーク構成図の手動更新が辛い？よろしい、ならばCloudMapperだ
Prometheus入門から運用まで徹底解説
開発者が運用を経験すべき一つの理由 | DevelopersIO
開発者の開発ペースを落とさずに強固なインフラストラクチャ・セキュリティを実現するためには - ITnews
インシデント指揮官トレーニングの手引き | Yakst
組織に対してSREを適用するとどうなるか
TVer Tech Blog - TVer Tech Blog
Microservices Architect in DMM Platform - DMM inside
突撃！隣のDevOps 【はてな編】 | DevelopersIO
Go 言語のプロファイル機能とネットワークコネクションにまつわるトラブルシューティング
SREこのへんで苦戦しがちじゃないですか？
SRE に成る君に最低限の開発力を身に着けてほしい - じゃあ、おうちで学べる
PairsにおけるSLI/SLO再定義
Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜