スクウェア・エニックスの"とあるシステム"のSite Reliability Engineering
はじめに こんにちは、情報システム部 SRE 橋本です。 普段はクラウドエンジニア(SRE)としてチームリードをしています。興味関心がインフラ、Observability、SRE、Security、Golangといった分野であり、 Japan Google Cloud Usergroup for Enterprise(Jagu’e’r ジャガーと読みます)でObservability/SRE分科会のオーナーを担当させていただいております。その縁もあって先日Innovators Hive at Cloud Next 2022でコミュニティ運営についてお話をさせていただきました。 この記事では現在チームリードをしていてビルドアップ中でもあるSREチームについて考えていることをお話したいと思います。 また、このSREチームについてのインタビュー記事も掲載いたしました。メンバーやチームの雰囲気を伝
身に覚えのない170万円の請求が……AWSの運用管理で起きた“4つのしくじり”
「AWSを使って構築したお客さまの環境を日々運用していく中で、これまでさまざまな失敗を経験してきた」――アイレットの古屋啓介さん（クラウドインテグレーション事業部インフラエンジニア）は、クラウドインフラの運用管理者向けイベント「Cloud Operator Days Tokyo 2020」のセッションでこう明かした。 アイレットはクラウド専業のSIer。AWS（Amazon Web Services）のマネージドサービス「cloudpack」なども提供しているが、細かい仕様の見落としなどが原因で、cloudpackの運用でいくつかの“しくじり”があったという。 身に覚えのない170万円の高額請求がAWSから来た 古屋さんによると、特に印象に残っている失敗は4つ。その1つ目は「Amazon Athena」で170万円の請求が来たことだ。 AthenaはAWSが提供するPaaSで、オンラインス
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
インフラエンジニアからSREへ ～クラウドとSaaS活用が変えるサービス運用のお仕事～ - 一休.com Developers Blog
2018年4月、データセンター完全クローズ 一休は、今年の4月にデータセンターを完全にクローズしました。現在、すべてのサービスをAWSを使って提供しています。 この過程で各種運用ツールやビルド/デプロイのパイプラインなどをすべて外部サービスを使うように変更しました。 これによって、インフラエンジニアやサービス運用担当者の役割や業務が大きく変わりました。本稿では、その背景を簡単に紹介したいと思います。 ざっくり言えば、 物理サーバのセットアップ&データセンターへの搬入のような仕事はなくなった。 アプライアンスの保守契約、パッチ適用、運用ツールのバックアップのような仕事もなくなった。 各種メトリクスを見ながら、Infrastructure as Codeでクラウドリソースの管理や調整をする仕事がメインになった。 必要に応じて、プロダクトのソースコードに踏み込んで必要な改修を行い、サービスの安定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
