その監視、必要ですか？ - Qiita
この記事は検索エンジンプロダクトを一緒に開発してた同窓会のカレンダーの24日目の記事です。 この記事の想定読者 夜中にメモリ使用率超過のアラートを受け取ってるけど、特に何もする必要がない人 アラートの通知内容だけではよく分からないので、監視ツールの画面や本番環境の状態を目視で確認して影響確認してる人 この記事で想定していない読者 MSP事業者のようなITインフラの監視・安定化、それ自体を目的とされている方 労働の疎外 まずはカール・マルクスの話をしましょう。 マルクスの理論における「労働の疎外」には主に次の四つの側面があります 製品の疎外: 労働者は自分が生産する製品との関係を失います。彼らは自分の労働で作り出した物を所有せず、それが単なる商品として扱われます。 生産活動の疎外: 労働者は自分の労働過程との関係を失います。単調な作業により創造性が抑制され、仕事に対する個人的な充足感が欠けま
障害対応プロセスを改善してきた話 - 10X Product Blog
障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S
信頼性目標とシステムアーキテクチャー / Reliability Objective and System Architecture
SRE NEXT 2023で発表した内容です。 https://www.youtube.com/live/c_oMpshssRg?si=LfArG3rX4VXPJ30H&t=27643
Four Keysを用いた改善活動のアンチパターンと、本質的な改善のために必要な「なぜ？」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。株式会社リンクアンドモチベーションの川津（@KawatsuYusuke）です。こちらの記事では主に私たちがFour Keys メトリクスを元に、開発生産性向上を目指した活動に関する話題についてお伝えします。 と言っても、『LeanとDevOpsの科学』をはじめ、Four Keysの運用に関するトピックはすでに多く語られています。また、Four Keysは便利なメトリクスであるがゆえに、ときに「Four Keysを改善する」という手段が目的化してしまうことがあります。本稿では主にこれから開発生産性向上に取り組もうとしている方に向けて、私たちの取り組みと、体験したアンチパターンをもとに、「Four Keys改善の取り組みには "なぜ？" が大事」についてお伝えします。 私たちの開発生産性向上のはじまりと、目指すべき状態の設定 Four
運用に携わる人全員に見てほしい！ Ops Guidesの紹介 - Qiita
PagerDuty Advent Calendarの8日目！ 今日はOps Guidesのお話です。 うちはこうだけど、他はどうやってるんだろう？ 普段から運用に関わっていると、ふとした瞬間に「そういえば他の会社ではどういう運用をやっているんだろう？」と気になること、ありませんか？ そのきっかけは「本当になんとなく」といったものから「上手くいかない運用にフラストレーションが溜まって」というどす黒いものまで色々あると思いますが、いずれにせよ「他の会社の良いところを取り入れて、自分たちの運用を改善したい」という気持ちから来ているのは間違いないでしょう。 だからこそ、いろんなミートアップに参加して発表を聞いたり、懇親会で話してみたり、Xに垂れ流されているいろんなポストを読んで事例を学ぶわけです。 ベストプラクティスを学びたい! このような取り組みはとても良いことですし、是非とも継続して情報収集し
技術の洪水に立ち向かう: 開発者の心を軽くするプラットフォームエンジニアリングの話
Findy主催のイベント「なぜ話題？Platform Engineering最前線 〜いま注目を浴びている理由とは〜」 https://findy.connpass.com/event/298961/ でお話しした資料です
なぜ Four Keys を改善するのか？/productivity-con-link-and-motivation
【開発生産性Conference】 リンクアンドモチベーション登壇資料（2023/07/13） 『なぜ Four Keys を改善するのか？ 〜How ではなく Why を重視したメトリクス改善活動〜』 #開発生産性con_findy #リンクアンドモチベーション #リンモチ ============================================= 【イベント情報】 ■イベントページ https://findy.connpass.com/event/283417/ ■特設サイト https://dev-productivity-con.findy-code.io/ 【株式会社リンクアンドモチベーション】 ■お問い合わせ engineer_pr@lmi.ne.jp ■Entrancebook https://note.com/lmi/n/n179505e048f4 ■テック
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
モバイルチームの「エリートDevOps チーム」への道のり（我々のFour Keysも公開しちゃうよ） - Uzabase for Engineers
概要 どうやって指標を確認しているの？ NewsPicksのFour Keysはどんな感じ？ 改善前はどんな感じ？ 改善のために何をした？ 終わりに 概要 NewsPicksは「最高の開発体験の追求」をしている会社です。エンジニア向けのサイトの1ページでも謳っており、そこから弊社高山の記事に辿れるので、こちらも読んで頂けると幸いです。 そして、これはサーバーサイドだけの話しではなく、モバイルチームでも同じように開発者体験向上を目指し、Four Keysを追っています。 Four Keys とは、ソフトウェア開発チームのパフォーマンスを計測する4つの指標です。Four Keys 指標を用いることで、ソフトウェアデリバリの「スピード」と「安定性」を測定できます。 いわゆる組織の開発生産性が可視化できるということですね。 私が所属するモバイルチームもさまざまな改善をすることで、Four Keys
SRE 研修
SRE 研修 共有ログインお使いのブラウザのバージョンはサポートが終了しました。 サポートされているブラウザにアップグレードしてください。閉じる ファイル編集表示ツールヘルプユーザー補助機能デバッグ
「Pepabo Tech Conference 20 春のSREまつり」開催レポート - Pepabo Tech Portal
ホスティング事業部 SREチームでエンジニアをしている @takumakume です。 2023年4月14日に「Pepabo Tech Conference #20 春のSREまつり」を開催しました。 ペパボのSRE（Site Reliability Engineering）の活動内容を知りたい方は、ぜひ見ていただければと思います。 では、発表内容を紹介します。 ホスティング事業におけるSREの取り組みと面白さ (@takumakume) ホスティング事業部におけるSREの取り組みと面白さについて紹介しました。具体的な技術やアーキテクチャの課題解決方法、そしてSREの仕事の魅力を解説しています。 世にないアーキテクチャの創出や幅広い技術の取り扱い、そこから来るチャレンジングな仕事がホスティング事業部におけるSREの魅力です。 プロダクト開発エンジニアからSREへの挑戦：Embedded S
SRE Classroom: The Art of SLOs - Google
The Art of SLOsは、GoogleのCustomer Reliability Engineeringチームによって開発されたワークショップです。このワークショップの目的は、Googleがサービスの信頼性を計測する方法 サービスレベル指標(SLI) とサービスレベル目標 (SLO)を参加者に紹介し、実際にこれらの計測方法を作成することを体験してもらうことです。これらは重要で土台となる概念です。サービスの信頼性を客観的に測定する方法があれば、サービスの信頼性について有意義な会話をすることがはるかに簡単になります。 ワークショップの理論編では、開発チームと運用チームの間でしばしば生じる組織的な緊張を、サービスの望ましい信頼性を表す目標値を設定することで解決する方法を学びます。また、SLOとエラーバジェットを使って、データ駆動で、客観的、かつユーザー重視の方法でサービスの信頼性を測定・
WEARにおけるSLOを用いた信頼性改善の取り組み - ZOZO TECH BLOG
こんにちは、WEAR部バックエンドブロックの小山とSREブロックの繁谷です。 WEARでは日々システムの信頼性を向上させるため改善に取り組んでいます。今回はその中でもSLOに基づいた改善について紹介いたします。 WEARリプレイスの歩み WEARでは2019年から本格的にリプレイスを開始しましたが、当初は専属のSREはおらずインフラ構築など緊急度の高いものをバックエンドのエンジニアや、プロダクト横断のSREが担っていました。 WEARのSREとして活動に割ける時間も短かったためSLI(Service Level Indicator)1やSLO(Service Level Objective)2の指標もありませんでした。WEARにおけるリプレイスの変遷についてはこちらのスライドに詳しく載せられているため、ご興味のある方は是非ご覧ください。 WEARの組織における課題 WEARでは2021年4
freeeの社内異動制度「異動戦国」のチーム紹介を一挙公開 - freee Developers Hub
こんにちは、DevBrandingのellyです。 先日ブログでご紹介したfreeeの社内異動制度「異動戦国」、この時期になると社内では毎年、異動希望者を募集するために各チームの熾烈なPR合戦が繰り広げられます。 今回は、その際のSlackや社内WikiでのPR合戦の様子をご紹介します。募集期間中の社内の雰囲気やfreeeの開発組織にはどんな仕事があるのか、どんな魅力があるのかを知ってもらうきっかけになれば嬉しいです。 Slack上で繰り広げられた今年のPR合戦の様子 チーム紹介 SREチーム DBREチーム DXチーム IAM （認証認可基盤開発）チーム サービス基盤チーム 課金基盤チーム ERP基盤チーム データ基盤チーム コアエンジン（外部サービス連携）チーム AIラボチーム 会計チーム LEGO（Public API・アプリストア開発）チーム 人事労務チーム 金融チーム プロジェク
コインチェックでSLI/SLOを策定したときの話 - coincheck tech blog
Introduction はじめまして、SRE G の渡邉です。今回のブログでは、以前の弊社 VP of Engineering佐藤によるコインチェックでの DX Criteria の活用 https://tech.coincheck.blog/entry/2021/12/13/115048 にあった「SLI/SLO/エラーバジェットの決定」の話をします。 コインチェックでは、策定にあたってこんなことを考えて、こんな 感じのものを策定した、を紹介しますので、皆様のSLO策定・改善の役に立てていただけると幸いです 策定の経緯 SREとしてトイル削減やアラート整理などは進めていたのですが、それがある程度落ち着いてきてからは、SLOの策定はやらないといけないとは思いつつもその必要性から説明をしてつくっていくのは相当なパワーを使うのでなかなか手を付けられていませんでした。 それが、2020年の末あ
組織にSREの文化を作り上げていくEnabling SRE - Money Forward Developers Blog
こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。 先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。（今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。） その新しい体制の中で "Enabling SRE" というチームが生まれるのですが、Enabling SREとはどういうチームなのか？どういう背景で生まれたのか？何をやっていくのか？ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。 はじめに まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。 サービス基盤本部の体制変更の背景 マネーフォワード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「入門 監視」5年を経て変わったこと、変わらないこと / Fundamental principles in Practical Monitoring
ZOZOTOWNのProduction Readiness Checklistと信頼性向上の取り組み / Improvement the reliability of ZOZOTOWN with Production Readiness Checklist
非ITの事業会社にSREと言わずにSREを持ち込んだ
AWSからオンプレミスに移行したWebRTC配信サーバのその後 - DMM inside
