サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
アメリカ大統領選
sre-magazine.net
はじめに 株式会社primeNumber で データマネジメントを支援するSaaS TROCCO と COMETA の SRE をやっている髙塚 (@tk3fftk) です。 SRE Magazine 第5号はインシデントとか On-Call ネタが多そうな雰囲気を感じたので乗っかって On-Call 改善ネタを書いてみます。 TL;DR CTO の1人 Always On-Call 状態をなんとかするために、 On-Call ローテーションを整備しました。 また、単にローテーションを組むだけでは今後スケールしないことが予想されたため、以下の3つの施策を行いました。 On-Call への補償の導入 On-Call 担当者の責務を明確にする On-Call 担当者のハードルを下げる 読むといいかもしれない人 On-Call の仕組みや On-Call ローテーションを導入したい人、改善したい
AWS IAM Identity Center の棚卸しで権限クリープを防ぎたい 初寄稿の @wa6sn です。8/3-4 に開催される SRE NEXT 2024 が楽しみですね。筆者の所属する 株式会社ギフティ も、GOLD スポンサーとしてブースを出しています。ノベルティも配っているので、ぜひお立ち寄りください。 さて本題ですが、今回は AWS IAM Identity Center で付与したアクセス権限の棚卸しについて述べます。SRE をやっていると、こうした AWS アカウントに対するセキュリティ対策に関わる機会も多いのではないでしょうか、ということで書いてみました。なお、筆者の環境では Control Tower を利用して全アカウントで CloudTrail を有効化しつつログを一元保管しているという前提があります。 権限クリープ マルチアカウント運用が広まっている昨今では
巻頭言:SRE NEXT 2023のプロポーザルを作る時に考えていたこと 書いた人:しょっさん( @syossan27 ) SRE NEXT 2024がそろそろ開催ということで、SRE NEXT 2023のプロポーザルを作る時に考えていたことについて書きました 自動テスト可能なインフラプロジェクトの設計について 書いた人:Jun Fujita( @erueru_tech ) プロダクトを構成する各レイヤの中でも 1、2 を争うほどにテストが難しいインフラの領域で、よりテスタブルなインフラ開発を実現するためのプロジェクト設計に関する話 Embedded SREの実践: 開発チームから始めるSRE推進 書いた人:Kuniaki Moriya( @Zepprix ) スタートアップの一人目 SRE が開発チームの中から信頼性向上に取り組んでいる事例のご紹介 ペアーズのバッチ実行基盤の品質を定義し
はじめまして、クリエイティブサーベイ株式会社の大澤(@ohsawa0515)と申します。 Sansan株式会社でITインフラエンジニアとデータエンジニアをした後、2024年1月からグループ会社のクリエイティブサーベイに出向して、SREチームのかたわら、データエンジニアチームにEmbedded SREとしても活動しています。 AWSのコストを分析・可視化する場合に、AWS Cost Explorerを使うことが一般的ですが、より詳細な分析を行う場合にはAWS Cost and Usage Reports(AWSのコストと使用状況レポート、以下CUR)を利用することがあります。CURはS3バケットにCSVもしくはParquet形式の請求データを定期的に出力する機能で、Amazon AthenaやAmazon Redshift、Amazon QuickSightといったAWSサービスによってクエ
巻頭言:一人SREsのドキュメンテーション実践 書いた人:しょっさん( @syossan27 ) 一人でSRE活動をやっている中で実践しているドキュメンテーションに関するTipsと、最後に来年開催致しますSRE Kaigiの話を少しいたします。 ECSプロダクトの監視をTerraform Moduleで標準化 書いた人:@rubita_isi ECSプロダクトの監視をTerraform Moduleで標準化した件について、その背景や具体的な内容についてお話しします。 入門 ポストモーテム 書いた人:渡部龍一( @ryuichi_1208 ) ポストモーテムを行う流れとその際に気を付けていることなどについて書きました。 AWS Cost and Usage ReportsをSnowflakeからクエリする 書いた人:@ohsawa0515 AWSコストを分析・可視化するためのAWS Cost
自己紹介 はじめまして、ENECHANGEの@rubita_isi です。 普段はWEBアプリケーションのバックエンドやインフラの開発や運用を担当しています。 この記事では、AWS上に構築された膨大なWEBアプリケーションをElasticBeanstalkからECSに移行する際に、 監視をTerraform Moduleで標準化した件について、その背景や具体的な内容についてお話しします。 ECS移行について ElasticBeanstalkからECSへの移行 ENECHANGEでは、WEBアプリケーションをAWSのElasticBeanstalkで運用していました。 しかし、ElasticBeanstalkを利用する場合、ホストOSやアプリケーション言語のバージョンが頻繁にサポート終了を迎え、その度に対応が必要でした。 また、ebextensionやplatform hookの仕組み・仕様
自己紹介 株式会社モニクルで SRE をしている beaverjr です。 この記事では、弊社のプロダクトチームと SRE チームで定期的に行っているプロダクションミーティングについて紹介します。 プロダクションミーティングとは プロダクションミーティングについては、SRE 本に詳しい記載があります。 プロダクションミーティングは、サービスが実際に運用される本番環境の状況と運用に関する情報共有を目的としたミーティングです。 ミーティングの目的 プロダクションミーティングの主な目的は、以下の通りです。 情報共有: チーム間での情報の透明性を保ち、本番環境に関連する重要な情報を共有します。 問題解決: サービスの運用パフォーマンスの詳細について話し合い、それを設計や設定、実装と関連づけて考え、問題解決の方法を議論します。 継続的な改善: 定期的なミーティングによって改善のサイクルを生み出し、サ
自己紹介 はじめまして、GMOペパボでSREをやっている渡部龍一(X: ryuichi_1208)です。業務以外ではSRE Nextのスタッフをやっています。普段は障害対応をしたりEOL対応をやったりしています。 この記事では、SLODocsの運用を1年ほど前に開始しました。本記事では実際に運用してみて得られた知見を共有します。 SLO Docsとは 「Service Level Objectives」に関連する文書です。内容は「なぜSLI/SLOが必要なのか」や「具体的な目標値」、「関連しているチームや変更のためのステップ」等をステークホルダー間で合意を取った上で運用しているドキュメントとなります。 WEB+DB PRESS Vol.130の中で取り上げらている「【第2回】プロダクト開発に必要なモニタリングの始め方……SLOを定義し,SLIを実装しよう」を参考に我々のサービス向けにアレン
この記事は株式会社 X-Tech5 CTOの、ばば(netmarkjp)が書きました。 事業でのコストコントロールは永遠の課題ですね。クラウドサービスのコストコントロールは昨年あたりから特に大きく取り上げられている印象です。 キーワードとしては「コスト削減」や「コスト最適化」がよく使われます。ここではまるっとコストコントロールと呼びます。 わたしはお仕事で色々な会社のSREの実践や体制構築をお手伝いするSREサービスや、SRE/オブザーバビリティの導入・定着支援をしています。 各種クラウドサービスのコストコントロールの機会も多々あるので、その中で得たクラウドサービスのコストコントロールにスムーズに取り組むためのヒントを共有します。 同じ成果なら支出は少ないほうが嬉しい 何をいまさら、という感じかもしれませんが、支出は少ないほうが嬉しいですよね。それはそう。 ただ、この「同じ成果なら」という
既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく、手動計装を選んだ理由を説明します。 GoアプリケーションへのOpenTelemetry計装手段 Goにおいては、OpenTelemetryの自動計装が公式で用意されていません。公式サイトにAutomaticの章がないことからわかります。おそらく、ランタイムの制約で実行時にアプリケーションの挙動を変えることが難しいのでしょう。 トレースに十分なスパンを含めるために、現状では以下の2つの計装手段があります。既存のGoアプリケーションに導入する手間や影響範囲をイメージいただくために、概要に絞って解説します。 手動計装 eBPFによる自動計装(Work In Progres) 1. 手動計装 まず、OpenTelemetryのSDKをインストールし、セットアップをします。 func main
これを参考にしているのでしょう、バーンレート14.4や6をアラートの閾値としている例をちらほら見かけます。 14.4には暗黙の前提がある しかし、先の表には暗黙の前提があります。SLOの期間が30日と仮定されているのです。 バーンレートの定義上、SLOの全期間でエラーバジェットをちょうど消費し終える速度が「1」です。 表の最下行でバーンレートが1なのは、期間が30日だからです。30日の10%=3日で、10%のエラーバジェットを消費するのですから、バーンレートは1となります。 計算式にすると下記の通りです。 2% * (30d / 1h) = 0.02 * 720 = 14.4 5% * (30d / 6h) = 0.05 * 120 = 6 10% * (30d / 3d) = 0.10 * 10 = 1 先の表と整合していますね。 SLO期間が28日だと13.44になる 一方で同書の2章
ありがたいことに第2号も発刊できました。ご協力いただけました皆様にここで感謝申し上げます。 今回の巻頭言は、Four keysの"Change lead time"についてちょっと深堀りしてみた話を書いていきます。 Four keysとは “State of DevOps Report"という、毎年DORA(Devops Research And Assessment)社によって発刊されている、DevOpsに関わるエンジニアのアンケートを元に統計を取り、考察・研究されたレポートがあります。 Four keysはその2014年度に発刊されたレポートで発表され、「ITパフォーマンスを測る指標」というものでした。(ITパフォーマンスってザックリした言葉ですね) そんなFour keysは以下の4つの指標で構成されています。 Deployment frequency(デプロイ頻度) Lead ti
巻頭言:Four keysの"Change lead time"をちょっと深堀る 書いた人:しょっさん( @syossan27 ) Four keysの指標の一つ、“Change lead time"について気になるところをちょこっと深堀りしてみました。 SLO期間が28日のとき、アラートの閾値をバーンレート14.4にしてよいのか 書いた人:iwamot さん( @iwamot ) SLOの期間に関わらず、バーンレート14.4をアラートの閾値としている例を見かけます。14.4が常に最適なのか、考えてみましょう。 GoプロジェクトへのOpenTelemetry計装でeBPF自動計装を採用しなかった話 書いた人:sumiren さん( @sumiren_t ) 既存GoプロジェクトにOpenTelemetryを計装する機会がありました。eBPFによる自動計装ではなく手動計装を選んだ理由を説明し
自己紹介 こんにちは、soma00333です。株式会社Industry TechnologyでCTOとして活動する傍ら、株式会社enechainでSREの仕事にも携わっています。 SREの仕事に大きなやりがいを感じる一方で、Platform EngineeringやSecurity分野への興味も持っています。 この記事では、ソフトウェア開発におけるアーキテクチャの意思決定とドキュメント管理の重要性に焦点を当て、「Architecture Decision Record(ADR)のすすめ」というテーマで話を進めていきたいと思います。 はじめに enechainにおけるソフトウェア開発では、アーキテクチャの意思決定とドキュメント管理に関して以下のような課題がありました。 アーキテクチャのAs-IsとTo-Beの管理が不十分 アーキテクチャの現状と将来像の理解・管理は、開発プロセスにおいて重要で
SRE MagazineはSREに関連する記事や、SREに関係する人にスポットを当てたWeb雑誌です
はじめまして、しょっさんと申します。 この度、SRE Magazine始めました。 何故始めたのかというと、国内においてSREについての情報が集まる場があまり無いなと思っていて、無いなら作っちゃえということで以下のツイートで寄稿者を募ってみました。 【!募集!】 SRE Magazineという"るびま"のようなWebマガジンを始めたいのですが、SREに関する記事を投稿してもいいよ!という方いらっしゃいますでしょうか?👀 内容はどんなものでも問題ありませんので、気になる方はDM等でご連絡ください!🙏 また、拡散もしていただけると助かります!🙇 — しょっさん@ʕ ◔ϖ◔ʔ (@syossan27) March 3, 2024 有り難いことに多くの方に反応頂けたことで「これは自分以外にも需要はありそうだな」ということで、走り始めました。 このTwitterで反応を伺ってから走り始めるの
巻頭言:SRE Magazineを始めました 書いた人:しょっさん( @syossan27 ) SRE Magazineの発刊についての想いなどを書いてます。 ばばさんがお勧めする「SRE入門」と「SRE入門の入門」に効く書籍や文章 書いた人:ばば/netmarkjp さん( @netmarkjp ) SRE入門に効く書籍や文章を紹介しています。 非常時の可用性をフィーチャーフラグで保つアイディア 書いた人:iwamot さん( @iwamot ) アクセス急増などの非常時でも可用性を保つ手法に「緊急レバー」があります。この記事では、緊急レバーの実装にフィーチャーフラグを用いるアイディアを提示します。 SIEMってサイトの信頼性向上に寄与するの? 書いた人:Yuta Kawasaki(ゆーた)さん( @yuta_k0911 ) SIEM on Amazon OpenSearch Servi
このページを最初にブックマークしてみませんか?
『SRE Magazine』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く