TechFeed Experts Night#17 〜 事例で学ぶSRE 〜 ツール、プラクティスから組織づくりまで https://techfeed.io/events/techfeed-experts-night-17
ヤフー時代の部下から突然メッセンジャーが。 「以前宮坂さんが緊急対応時に残して頂いた言葉を今度セミナーで使っていいですか?」 と。 リーダーの仕事はいっぱいあるけどなかでも大きな仕事の一つは重大事故の発生の時の陣頭指揮。平時は部下で回せるようにするのがマネジメントだけど、危機の時まで部下にまかせるわけにはいかない。 お恥ずかしながらヤフー在職中の22年で何度か重大事故を起こし関係者の人に多大な迷惑をかけてしまった。その度にその陣頭指揮をとった。 結果的にヤフーのなかでもっとも深刻な事故対策をやった人の一人じゃなかろうか。そのなかからノウハウ的なものがたまってきたものを部下にメモしておくってあげたものを彼は覚えていてくれたらしい。 彼いわく危機対応の時にすっごく役にたって指針になったといってくれて送ってくれた。 ひょっとしたら他の人にも参考になるかとおもって(若干訂正してますが)ここに残して
※この投稿は米国時間 2019 年 1 月 26 日に Google Cloud blog に投稿されたものの抄訳です。 このたび、『The Site Reliability Workbook』がウェブサイトで閲覧できるようになりました。Google で生まれ、他の企業にも広まりつつある Site Reliability Engineering(SRE)は、運用上の問題をソフトウェア的に解決するためのエンジニアリングであり、Google におけるエンジニアリングの本質的な部分を占めています。 SRE は考え方であり、一連のプラクティスやメトリクスであり、システムの信頼性を保証するための処方箋でもあります。SRE モデルを構築すれば、サービスの信頼性が向上し、運用コストが下がり、人間が行う作業の価値が高くなって、サービスとチームの双方で大きなメリットが得られます。上述の新しいワークブックは、
ソフトウェアエンジニアリングと一見関わりはなさそうで、しかしチームで成果を出す過程においてとても重要だと筆者が考えているコンセプト、 "Working Out Loud" について書いてみます。 日本語の記事がほとんど見当たらないのであまり知られている言葉ではないかもしれません。 対象読者 以下に興味や関心を持つ方を対象読者として想定しています。 チーム開発におけるコラボレーション手法 チーム開発者としての振る舞い方 テックリードやスペシャリストの育成 が、本心ではチーム開発する全ての方に届いてほしいです。 まえがき ある夜に同僚の@ujihisaと近場ないし遠方のEngineering ManagerやVPofEの皆さんと話す機会があり、その折にふと筆者がこぼしたのが 「開発などの日常の業務において自分がやっている以下の思考様式が大変便利なので、この考え方を最近入社したメンバーにもインス
メディア関係者向けお問い合わせ先 メールでのお問い合わせ: pr-jp@google.com メディア関係者以外からのお問い合わせにはお答えいたしかねます。 その他すべてのお問い合わせにつきましては、ヘルプセンターをご覧ください。
はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一
2つの開発現場を見てみましょう。 ※この物語はフィクションです 開発現場A ビジネスチームが一生懸命アイデアを出して、それを開発チームに依頼する。依頼を受けた開発チームは、要件を確認しながら開発計画を立て、数ヶ月にリリースをするスケジュールを組んで、開発を開始した。 ビジネスチームは、開発期間の間にいろんなことを想像し始める。 競合サービスを研究していると不安になり、「あれがないとダメ!」「これもないとダメ!」という気になって、最初の想定よりもプロダクトはどんどん太っていく。 こういう状況で追加されていく要望は当然ながら検証されていない想像=妄想なので、実際にリリースしててもユーザーに使われるかどうかはわからない。 * なぜあなたのチームの プロダクトは太ってしまうのか #postudy // Speaker Deckより 当然ながら開発チームは当初想定していたよりもやることがどんどん増え
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
最近ユビレジではじめた Slack チャンネルの新しい運用 なんですが、ユーザーサポートから開発者への問い合わせが作成されると自動でそれに対応する Slack のチャンネルが作成される。それは開発者全体チャットみたいなチャンネルに通知される。ユーザーサポートから開発者に問い合わせがくる場合というのは、大抵なんらかのソフトウェアの不具合である。 するとその問い合わせにある問題について知識のある開発者がそのチャンネルに入ってあーでもないこーでもないみたいに議論しながら対応してサポート担当者やら関連する案件の提携先企業やらとやりとりする。また障害であればそこで対応作業の内容を逐次事前に通告して他のメンバーのレビューを仰いでから行う。結果についても遅滞なく報告する。 このようにしているといずれ障害や問題は解決するので、その時点でそのチャンネルはアーカイブして社内 Wiki に簡単な概要を作成する。
プロダクトの分析全般を担当している@hikaruです。 日々、メルカリのプロダクト改善のPDCAを定量分析の面からサポートしております。 以前、メルカリのデータサイエンティストが日々どのようなツールを使って分析をしているのかをお伝えしました。 tech.mercari.com このエントリーでは、メルカリの分析チームの活動をもっと知ってもらうために、先日メルカリで行われた「Drink Meetup with Mercari (BI/ML)」の様子をお伝えしようと思います。 mercari.connpass.com ちなみに、ご存じない方もいると思うので説明しておくと、Drink Meetup with Mercari はメルカリの各チームがどのように働いているかを外部の方々に知ってもらうために、職種やテーマ別に行われるドリンクミートアップイベントです。 既に53回目となる今回のテーマは、デ
Help us understand the problem. What is going on with this article? 会社で働いていると、運用チームからの問い合わせがあると思います。 問い合わせというものは、割り込みに繋がり生産性を下げるのでなるべく減らしていきたいものです。 Redmineで管理されているオープンなチケットを10分の1に削減した話をまとめます。 常時、約50枚ほどオープンなチケットを5枚ほどに減らしました。 問い合わせが多くて辛みを味わっている方の参考になれば。 概要 Web自社サービス タスク管理ツール Redmine 毎日、5枚ほどチケットが増える 運用と開発がそれぞれ20人ほど こんな環境です。 改善のきっかけ うちのチームは、当番制で「問い合わせの窓口」(以下、窓口)となる人を作ります。 窓口の人がチケットを解決したり、有識者にチケットを委譲した
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く