PHPカンファレンス小田原2024での発表です。 #phpcon_odawara
巻頭言:SRE Magazineを始めました 書いた人:しょっさん( @syossan27 ) SRE Magazineの発刊についての想いなどを書いてます。 ばばさんがお勧めする「SRE入門」と「SRE入門の入門」に効く書籍や文章 書いた人:ばば/netmarkjp さん( @netmarkjp ) SRE入門に効く書籍や文章を紹介しています。 非常時の可用性をフィーチャーフラグで保つアイディア 書いた人:iwamot さん( @iwamot ) アクセス急増などの非常時でも可用性を保つ手法に「緊急レバー」があります。この記事では、緊急レバーの実装にフィーチャーフラグを用いるアイディアを提示します。 SIEMってサイトの信頼性向上に寄与するの? 書いた人:Yuta Kawasaki(ゆーた)さん( @yuta_k0911 ) SIEM on Amazon OpenSearch Servi
技術的負債はどこにでもある タイトルにあるように、 いくつかの開発チームと一緒に技術的負債を改善する開発や、それらに関する活動を行うことが多く いろんな取り組みをしていく中で、よかったことがいくつかありました。 もちろん技術的負債を返すのは数ヶ月で終わるレベルのモノは多くなく、 何年から十数年もかかるものの方が多いはずですので、 すべて完了しているわけではないですが、その活動の中であくまで「今のところよさそう」というレベルのものです。 何番煎じかわからないくらいのものですが、 これを読んだ方が取り組んでいくにあたってヒントになればと思います。 普通の話しかありません。 会社全体で合意とSRE これは当たり前ですが、念の為・・ 以前もイベントでお話しさせてもらったりしましたが、 技術的負債は開発体験が悪くなり、モチベーションが上がらなくなるものでもあり、 そこから招く生産性の低下や色々なネガ
サイバーエージェントは創業来、インターネット産業の拡大とともに事業成長を続けてきました。またそれと同時に、SRE領域へも注力してきました。SRE Technology Mapは、サイバーエージェントのSREチームの取り組みを知ってもらうことを期待して製作しています。 Developer Experts of SRE 柘植 翔太 Shota Tsuge サイバーエージェントが提供する幅広い事業サービスの信頼性向上に、私達SREsは日々取り組んでいます。事業領域や事業フェーズ、組織規模が異なれば、SREsのアプローチも違ってきます。それぞれのSRE組織が、様々な課題解決に取り組んだことによって得られた知見や考え方などを多くの人に知ってもらいたいと考え、「SRE Technology Map」を作成しました。 「SRE Technology Map」を通して、少しでもサイバーエージェントに興味を
ドキュメンタリアンとは、役職に関係なく、ソフトウェア業界でドキュメントとコミュニケーションに関心を持つ人のことです。 www.writethedocs.org はじめに これは主に『ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング』の書評です。私はSreakeにてSREという役職についています。SREはサービス概要、アーキテクチャの解説や図、各種構成図、各種手順書、ポストモーテム、ポリシー、SLA(SLO) … その他の様々な場面でドキュメントを書く必要があります。しかし、ドキュメントは価値が見えにくく時間と労力がかかり品質担保の面で重要度がとても高いのにその場での価値が見えにくいので浸透しにくいです。そのため、エンジニアとしてモチベーションが保ちづらいです。2021年 State of DevOps 2021 にもドキュメントに関する言及があり今後、
Google が過去に出版した 2 冊の書籍「Site Reliability Engineering」と「The Site Reliability Workbook」は、サービスライフサイクル全体への取り組みによって、組織がソフトウェアシステムの構築、展開、監視、保守を成功させる方法と理由を示しています。本レポートでは、Google Cloud Reliability Advocate の Steve McGhee と Google Cloud Solutions Architect の James Brookbank が、組織で SRE を導入する際にエンジニアが直面する特定の課題について深く掘り下げています。 SRE の普及にもかかわらず、多くの企業では SRE に対する当初の熱意と、その採用の度合いの間に大きな隔たりが生じています。本レポートは、プロダクトオーナーや信頼性の高いサー
この記事は、開発生産性 Advent Calendar 2022の24日目の記事です。 株式会社スマートショッピングでSREをしているbiosugar0です。 今回はSREが現在DevOpsに向き合い、開発を加速させるために取り組んでいることについて紹介します。 開発を加速させるDevOpsという考え方 DevOpsは、開発チームと運用チームが協力し、よりスムーズに高品質なサービスを作り上げるという考え方です。 歴史的に、企業は複雑なシステムを開発運用していくために「開発」と「運用」という別々のチームにそれぞれの仕事を任せてきました。 このアプローチに伴う開発/運用の分断には、多くの問題がありました。 その中でも大きい問題は、2つのチームの目標が対立関係に陥りやすいことです。 開発者は新しい機能や改修をスピード感をもって開発してリリースしたい、運用者はシステムをより安定させるためにシステム
What is OpenSLO?OpenSLO is a service level objective (SLO) language that declaratively defines reliability and performance targets using a simple YAML specification. It is released under Apache 2.0 and we welcome contributions from the reliability engineering ecosystem. SLOs are reliability targets for services that allow organizations to make better decisions in how to create, operate, and run cl
NewRelic / Elasticsearch ではじめるSREに必要な性能監視入門 https://supporterzcolab.com/event/177/ にて話した資料です!
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く