組織改善提案をするエンジニアを見て - tawara's blog
すごいなーと単純に思ってる。最近入社されたエンジニアはキャリアが長い方が多い。timesとかに勝手に入ってその仕事ぶり？というか考えてることなどを垣間見れて勉強になっている。 エンジニアとしての技術スキルもさることながら、ある程度大きなサービスの運用経験がある方たちなのだろう、どしどし改善案を提案してくれている。 コードレベルでいえば、開発体験を悪くしている箇所を指摘して自らタスク切ってPRを出したり、ディレクトリの切り方ぜんたいを見直してこんなふうにすると責務がより明確になるのでは、とか。インフラチームに入った方は直近のアラートに関して分析をして要否の整理や運用プロセスの改善案を提案している。みなさん入社してまだ2ヶ月も経っていない。 もちろんすべての提案が通るわけではないと思う。SUPER STUDIOには独自のやり方があるはずだし、改善をするべきタイミングなのかなどの検討の余地はある
SREは運用チームだけの問題？ 開発者のメリットをGoogle×スリーシェイクがプラクティスとともに解説！
もともとSREはGoogleがサイトの信頼性を高めるために、新しい部署を作り、ゼロから作りあげたものだ。今回はGoogleでオブザーバビリティ領域を担当する山口能迪氏とともに、SREの歴史や原則を確認し、アプリケーション開発者にも恩恵がある部分について語り合ってもらった。 株式会社スリーシェイク Sreake事業部 部長 手塚卓也氏 信頼性向上のためにGoogleが作りあげたSRE、その現在地とは ――まずはこれまでのご経歴や現在の役割について簡単にお聞かせください。 手塚：2016年にインフラ系ベンチャー企業に就職しインフラエンジニアとしてキャリアをスタート、スリーシェイクには2018年に入社し顧客企業へのSRE立ち上げ支援などを行ってきました。現在はSRE総合支援やセキュリティサービスを展開しているSreake事業部の部長としてチーム全体を見ています。 山口：前職は外資系パッケージベン
4月新刊情報『システム運用アンチパターン』
『システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション』 Jeffery D. Smith 著、田中 裕一 訳 2022年4月12日発売予定 352ページ ISBN978-4-87311-984-7 定価3,520円（税込） 上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニア
マイクロサービスの失敗は技術だけの問題か――Amazonに学ぶ開発・運用組織の理想形とは
開発と運用の理想的な関係とはどんな姿か。すでに「DevOps」という言葉は浸透しているものの、理想的な形で実践できているかとなると、話は別だ。現場ではどんな障壁があり、DevとOpsが分断されているのか。打開していくにはどうしたらいいのか。DevOpsという言葉が生まれる前から、その本質を実践してきたAmazonのカルチャーにヒントがありそうだ。AWSジャパン 塚田朗弘氏に聞いた。 今回お話を伺った、アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 塚田朗弘氏 ペアで語られてしまいがちな「マイクロサービス」と「コンテナ」 Amazonには「DevOps」や「マイクロサービス」という言葉が生まれる前から、DevとOpsを統合し、システムはAPIでやりとりするという原則がある。それを長年追求するなかで、開発カルチャーを育んできた。そんなAmazonから開発と運用の理想の
組織開発の意思決定透明化のために ODDR を試すことにしました | DevelopersIO
こんにちわ。てぃーびーです。 最近システム開発界隈でたまに話題をみかける「ADR」。 ADR は Architectural Decision Records の略で、アーキテクチャーの意思決定を決まったフォーマットで記録し続ける手法です。アーキテクチャーの意思決定後、時間の経過とともに当時のアーキテクチャーを設計した人が異動や退職で不在になり、後任が現在の設計を検討する上で、なぜ現状のアーキテクチャーになっているか確認したい、といったときがこの記録が活用される典型的なケースです。それ以外にも人の記憶は不確かなため、意思決定をした本人にとっても記録は便利です。 そういった必要性に関して niku さんの以下の記事が参考になります。 2020-05-19 ADR(Architectural Decision Records)を書くと決めた理由を自分の言葉で書き出した｜ヽ（´・肉・｀）ノ｜no
エンジニアが改善に取り組んだ、スカウト運用のナレッジを公開 - Gaudiy Tech Blog
こんにちは。エンタメ領域のDXを進めるブロックチェーンスタートアップ、Gaudiyでバックエンドを担当しているkei（@kei32bit）です。 エンジニア採用は、どの企業も苦戦しているのではないかと思います。Gaudiyでも今年の4月頃から本格的にエンジニアのスカウト運用を始め、エンジニアと人事が協力して改善を進めてきました。 最初は苦戦していましたが、徐々に「どのようなスカウト文を書けば返信が返ってきやすいか」「エンジニアと人事でどう連携すると良いのか」がわかってきて、一時は週平均で20%近くまで低迷していたスカウト返信率が、ここ数週間は35〜50%にまで向上しています。（もちろん波はありますが、9月は月平均でも41%でした。） そこで今回は、「採用に関わっていきたいけど、どう関わればいいのかわからない…」「スカウトの返信率を高めたい」といった課題感をもつ方々のご参考になればと思い、G
Kubernetesは、ITを「チケットドリブン」から「インテントドリブン」へ変えていく。Cloud Operator Days Tokyo基調講演
Kubernetesは、ITを「チケットドリブン」から「インテントドリブン」へ変えていく。Cloud Operator Days Tokyo基調講演 クラウドの運用担当者にフォーカスしたオンラインイベント「Cloud Operator Days Tokyo」では、8月27日に基調講演として、Kubernetesの生みの親の一人であるクレイグ・マクラッキー氏のセッション「Kubernetes and the Cloud Native Journey」が公開されました。 マクラッキー氏は、Kubernetesがインフラを抽象化することでオンプレミスからクラウドへの架け橋になること、Kubernetesが備える、システムを意図した状態へとコントロールする機能が、ITをチケットドリブンなものからインテントドリブンなものへと変える力があることなどを示しました。 ここではそのマクラッキー氏の講演をダイ
Looker を運営する組織を考察してみる | フューチャー技術ブログ
はじめにフューチャー夏の自由研究2021の9回目です。こんにちは、TIG DXユニットの西田と申します。 業務で GCP のインフラの設計/構築/運用を担当しております。私が感じている『GCP の特徴』というと、Gartner の Magic Quadrant などでも毎回紹介されているデータ分析領域だと思っています。 そのため今回は、 Google社が買収したLookerという技術の簡単な紹介 そして、それを使うとなった場合、何が必要になるか？ Looker を採用するメリットに関しては本記事では特に触れません。 経営層から、使う事が決定された前提での話になっています。 という事を考察してみます。 本記事はあくまでも自由研究であり、私自身は Looker の運用経験はない中での私の主観がメインです。そこは最初に申し上げておきますが、ご容赦ください🙇 Looker とは？概略Gartne
AWS初心者でもサーバレスでここまでできる――クラウド運用の定型業務を9カ月で自動化した新入社員の挑戦
AWS初心者でもサーバレスでここまでできる――クラウド運用の定型業務を9カ月で自動化した新入社員の挑戦：特集：「惰性をやめる、慣習を疑う」こんどこそ楽になる運用管理（2） 運用管理者に光を当てるオンラインイベント「Cloud Operator Days Tokyo 2021」。NTT東日本のセッション「新入社員が9ヶ月でクラウド運用の自動化システムを作ってみた」から、AWS初心者が運用監視の定型業務を自動化する際の流れ、苦労するポイントを学ぶ。 日々、何げなくこなしている業務の多くは定型業務だ。自動化することで一気に効率を引き上げることができる――そんなミッションに取り組んだのは、Amazon Web Services（AWS）に触ったのが入社してから初めてという東日本電信電話（NTT東日本）の新入社員、坂齊史奈子氏。 「Cloud Operator Days Tokyo 2021」のセッ
エンジニアの採用情報をまとめた GitHub Repository を公開しました #GameWith #TechWith - GameWith Developer Blog
ごぶさたしています。@serima です。 このたび GameWith では採用情報をまとめた GitHub Repository を公開しました。 github.com 採用に関する情報の分散化問題 GameWith ではエンジニアを積極採用中ですが、いざ採用候補者の立場にたってみると情報が各所に分散しており、せっかくの情報発信が十分に届いていないのではないかと感じていました。 たとえば年単位で運用している技術ブログの記事のなかで、どれが現在の会社の雰囲気や開発スタイルを適切に伝えているものなのかは外からでは分かりません。 さらに昨今は、採用にまつわる情報があらゆる媒体に分散して掲載される傾向があり、候補者視点では情報の収集も一苦労です。 特に、なかの人のインタビュー記事は自社運用の Wantedly や外部の求人媒体などそれぞれで掲載されたりする傾向が強いように思います。 さまざまな媒
Googleドライブをファイルサーバーとして活用する｜吉田航
過去数社で数年にわたってGoogleドライブを社内のファイルストレージとして運用し、ノウハウも溜まってきたのでまとめておきます。 なお、Googleドライブはクラウドストレージでありファイルサーバーではないので、タイトルは厳密には「従来のWindowsファイルサーバー代わりにGoogleドライブを利用する」という意味合いです。 この記事は「情シスSlackアドベントカレンダー2020#1」の23日目の記事でもあります。 はじめにGoogleドライブはGoogle Workspace（旧G Suite）で利用できるクラウドストレージです。 Boxのようなストレージに特化した製品には敵わない部分も多いですが、Google Workspaceを導入しているベンチャーも多いですし、 「そろそろファイルサーバーが必要だけど、オンプレのNASはちょっと…」 といった状況の会社には丁度良いと思います。
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
ユーザーの幸福度を定量化――SLI、SLO実践の4ステップ
SREは計測、自動化など取り組むことが多く、求められる知識量も少なくない。また周囲の理解が得られなければ、組織でSLI、SLOを定義してSREを実践するのも容易ではない。組織でSREに取り組む最初の一歩をどう踏み出せばいいのか。 企業がITを通じて新たな価値を提供することが必須要件となる中、顧客接点となるアプリケーションやサービスの重要性はさらに高まっている。価値提供を通じて競合優位性を保つには、新たなアプリケーションや機能の開発はもちろん、注目を集める「クラウドネイティブ技術」などを試していくことが不可欠だ。だが、その裏ではアプリケーションやサービスの安定稼働も求められる。 つまり、組織には新しい変化への取り組みが評価される開発者と、安定稼働を実現することで評価される運用管理者が存在する。相反する目標を持つ開発者や運用管理者に対し、「DevOps」という考え方も広まったが、実際にどう意思
どのようにPlatformチームの組織変更をしたか | メルカリエンジニアリング
Platform チームの@deeeeeeeetです． Platform チームは2年前にMercariがMicroservicesの移行を始めたときに一緒に立ち上げられたチームです．Platform チームはMicroservicesを動かすための基盤や開発や運用のためのツールセットなど提供しています．立ち上げ時は自分を含めて2-3人で始まったチームですが2年が経ち10人を超えるチームにまで成長しました． チームのメンバーが増えるほど1チームとして動くには限界がきており，またMicroservices化が進めば進むほどチームの負う責任範囲も広くなりCognitive load (認知負荷) も高くなっていました．これらの課題を解決するために組織変更を行い，Platform チームを複数の専門性に特化したチームに分割しました． 本記事ではチームのデザイン，チームが分離しても独立性を保ちつつ
DeNAがデータプラットフォームで直面した課題と克服の取り組み
はじめにこんにちは。この記事はDeNAの小口（Rikiya Oguchi）と長谷川（Ryoji Hasegawa）がお届けします。 小口はゲーム事業部の分析部データエンジニアリンググループの所属で、長谷川は全社共通部門である分析推進部の所属です。ゲーム事業部と全社部門で所属は違いますが、近しいミッションのもと、普段から密に連携して仕事をしています。 DeNAでは現在、データプラットフォームの刷新を進めています。この記事では、そのプロジェクトについて、以下の流れでご紹介します。 現行データプラットフォームの背景と概要データプラットフォーム構築後の環境変化現行データプラットフォームが抱える課題現行組織が抱える課題データプラットフォームの刷新刷新後のシステム構成組織体制の刷新我々と同じようにデータプラットフォームの構築・運用に携わっている方々や、データプラットフォームを利用されている方々、特に、
【CTO・エンジニアマネージャーに聞いた】エンジニア組織で大切なのは「その会社らしさ」と「納得感」。エンジニア評価制度運用まとめ | Findyブログ
FindyFindyブログエンジニア採用【CTO・エンジニアマネージャーに聞いた】エンジニア組織で大切なのは「その会社らしさ」と「納得感」。エンジニア評価制度運用まとめ 【CTO・エンジニアマネージャーに聞いた】エンジニア組織で大切なのは「その会社らしさ」と「納得感」。エンジニア評価制度運用まとめ 2020.02.20 Findy Teamsの石川（@HRBizDev1）です。 前回、企業の成長フェーズにおける5段階別エンジニア組織の課題と取組事例を書き、様々な方からの反響をいただきました。 今回は上場企業から創業初期のスタートアップまで、様々なフェーズの企業数十社のCTOやVPoEへヒアリングを重ねる中で感じた「エンジニアの評価制度を運用する上で大切なポイント」について書いてみました。 評価制度の運用を考えるにあたって、今回の記事が少しでもエンジニア組織運営の参考になりますと幸いです。
「SRE NEXT 2020」にdelyが協賛＆登壇しました！ - dely Tech Blog
こんにちは。delyのSREの井上です。 delyは先日開催されたSRE NEXT 2020にGOLDスポンサーとして協賛をさせていただきました！当日はセッション枠を頂き、「delyにおける安定性とアジリティ両立に向けたアプローチ」をテーマに発表もさせていただきました。 セッションでは、 前半：SRE本に則った理論の話 SREはプロダクト開発の速度を安全に高めるために存在しているということ プロダクト開発の速度を安全に高めるためには単純さを追求することが重要であること 後半：前半の理論に則ったdelyでの実践の話 をしました。スライドは公開済みですが、それだけだと伝わりにくい内容も含めてブログにも投稿させていただきます。 当日は多くの方が参加されていました！ SRE NEXTに参加してみて SRE Loungeの勉強会は#5以降の会は全て参加させて頂いているのですが、いつも有意義な情報が得
運用技術者組織の設計と運用 / Design and operation of operational engineer organization
第12回 インターネットと運用技術シンポジウム（IOTS 2019）～運用管理する人”も”報われるシステムの構築を考える～ にて招待講演を行った際の資料です。 概要: https://www.iot.ipsj.or.jp/symposium/iots2019/ プログラム: https://www.iot.ipsj.or.jp/symposium/iots2019-program/
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サイト信頼性エンジニアリングのドキュメント
