ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
ssmonline #43 での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
過去の賢人に学ぶ、インフラ運用チームのマネジメント失敗事例 - Qiita
gumiアドベントカレンダー9日目です。 今回はちょっと技術的なことを離れて、チームマネジメントまわりのことを書いてみようと思います。 1.チーム背景 私の所属しているチームは、主にAWS環境の運用を行っています。 チームメンバーは、ほぼ私が1人で対応していた時期から、数人規模のチームを推移してきました。 「愚者は経験に学び、賢者は歴史に学ぶ」とはよく言ったもので、残念ながら私は完全に前者になってしまいました。 改めて自分の失敗を振り返ると、良書と呼ばれる本には、失敗内容に関連した内容が記載されています。 特に、【Team Geek】の内容は、以前読んだ筈なのに全く実践できていなかったなあと。。。 【参考】『Team Geek』を読んだメモ 今回は、私のチームマネジメント失敗事例やそこから学んだことを徒然なるままに書いてみようと思います。 2.失敗したこと 2-1.メンバーの増加タイミング
インフラチーム改め Site Reliability Engineering (SRE) チームになりました | メルカリエンジニアリング
インフラチーム改めSite Reliability Engineering チームの @kazeburo です。この記事ではまだ馴染みの薄い Site Reliability Engineer とは何かについて紹介したいと思います。 SREとGoogleのSRE Site Reliability Engineerは日本語にすると「サイト信頼性エンジニア」となりますが、あまりキャッチーではないので普段は略語の「SRE」を使用しています。SREという職種は日本ではあまり聞く事はありませんが、FacebookやAirbnb、Dropboxなどの企業でSREが募集され、それぞれのサービスを支える重要な役割を担っていると思われます。中でもSREのパイオニアとしてGoogleのSREチームが有名です。 GoogleのSREチームはGoogleの検索、広告、Gmail、YouTube、App Engin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
