はてなブックマーク

はじめに こんにちは。Datadog Japan で Sales Engineer をしている 木村健人(AoTo)です。 Google Cloud の公式ユーザーグループ Jagu’e’r(Japan Google Cloud Usergrouup for Enterprise) では、Observability-SRE 分科会の運営をしています。 システムに携わる方々(開発者・運用者・プロダクトマネージャーなど)がオブザーバビリティを導入し実践するまで、どのような道のりを辿れば良いのでしょうか。 ある日 SRE としての役割を受け持った際、どのような過程を経てオブザーバビリティの実践へ至るのでしょうか。 本記事では、日々の業務やコミュニティで関わる方々を参考に、どのようにして SRE を浸透させオブザーバビリティの実践まで辿り着くかを「SRE の要素」と共に考察します。 免責事項 本記

はじめに こんにちは。しょっさん（@syossan27）です。 今回は、SREのアンチパターンについて軽くですが探求してみます。 アンチパターンについて SREのアンチパターンというと、「SREの探求」における23章にパターンの一覧と、その解決法が記載されています。 まずはこれを改めて紐解いてみましょう。 SREの探求でのアンチパターン ■ サイトリライアビリティ オペレーション 業務内容や権限の見直しを行わずに、運用 → SREという看板を掛け替える ■ 画面を見つめる人間 問題の発見を、人間の目による監視に依存し、自動化されたアラートや監視システムを導入しない ■ 群衆によるインシデント対応 インシデント対応する人員を最適な人数で行うことを考えず、全員で取り組む ■ 根本原因=ヒューマンエラー 根本の原因がヒューマンエラーという結論に至る 『善意の人間でも「壊す」ことができるのなら、そ

みなさんこんにちは！インシデント管理SaaSのPgaerDutyでプロダクトエバンジェリストをつとめているjacopenです。 さっそくですが、みなさんは普段、SREのプラクティスについてどのように学んでいますか？ すでに刊行されている書籍を参考にしたり、Webの記事を参考にしたりでしょうか。SRE NEXTなどのカンファレンスやミートアップの登壇を参考にすることもありそうですね。 今回、そんなみなさんにご紹介したいのがOps Guidesです。これはPagerDutyがSREをはじめとした運用に携わる方に向けて発信しているドキュメントです。 めちゃくちゃ大事なサービスを運営しているからこそ得られるノウハウ 自分がPagerDutyに入社したのは10か月ほど前なのですが、入ってみてこの会社はものすごく運用のことを考え抜いているんだなと驚きました。運用に関するドキュメントがバシッと整備されて

はじめに 株式会社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 を有効化しつつログを一元保管しているという前提があります。 権限クリープ マルチアカウント運用が広まっている昨今では

はじめまして、クリエイティブサーベイ株式会社の大澤（@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の仕組み・仕様

この記事は株式会社 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

ありがたいことに第２号も発刊できました。ご協力いただけました皆様にここで感謝申し上げます。 今回の巻頭言は、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

自己紹介 こんにちは、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