はてなブックマーク

「Microservices時代の監視設計」と言うエントリーを書きたいのだけど、そもそもなんでMicroservicesで作る必要があるのかというところを先に書く必要があると感じたので私見を述べてみる。すでにMicroservicesで作っている人からすると「何をいまさら」と言う内容も多いかもしれません。 Microservicesでなぜ作るのか ドメイン分割のレイヤーの変遷 今は成長段階 Microservicesのメリットとアーキテクト クラウドはフレームワークになった 共有データベースアンチパターンとMicroservices設計 Microservices時代の監視設計 参考図書など Microservicesでなぜ作るのか 身も蓋もないことを書いてしまうと、これはもう「潮流がそうなっているから」ということだと思う。業界がそういうアプリケーションの作り方をしてノウハウを貯めていく流

tl;dr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビュ

この記事はジンジニアアドベントカレンダー2024 25日目の記事です。 人事選考で安易に使われがちで、避けたほうが良い判断軸の項目に「コミュニケーション能力」や「地頭」があることが良く知られています(要出展)。ここではなぜコミュニケーション能力を問わないほうが良いかについて論じます。 コミュニケーション能力4象限 コミュニケーション能力を同質か多様か、能動か受動かという2つの軸で以下の4象限に分けてみます。 コミュニケーションスキル4象限 内訳をざっと細分化すると以下のようになるでしょうか。 同質な人に共感する シンパシー 共感力 親和性 同質な人に共感してもらう 共鳴力 信頼構築力 受容力 多様な人を理解する エンパシー 寛容力 異文化理解力 多様な人に理解してもらう 説明能力 発信力 橋渡し能力 一言でコミュニケーション能力といってもこのように様々な要素が含まれており、個々人の認識のズ

システム障害が起こったときにどういう体制で望むか、エンジニア個人が障害に直面した時にどのような役割を受け持つのが良いのか。組織によって色々なパターンはあるでしょう。しかし、幸いにも「入門 監視」やSRE本に書かれている4つの役割分担が浸透しているので、それをベースに考えるのがファーストステップとしては良いのではないでしょうか。 入門 監視 ―モダンなモニタリングのためのデザインパターン 作者:Mike Julianオライリー・ジャパンAmazon SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム オライリージャパンAmazon ただ、小さな組織では障害時に4人もすぐに揃わない場合もあるでしょうし、そもそも4人もスタッフがいない、と言う場合もあるでしょう。そういった場合にもどうすればいいのか考えていきます。 役割分担の基本 「入門 監視」に

私がWeb業界に入ったのは、ハッカーに対する憧れからです。その原体験を大事にしたいという気持ちを今でも強く持っています。 もう20年近く前になりますが、Web2.0の時代、私は傍観者でした。世界ではGoogleを筆頭として、日本でも、はてな社などが、エンジニアドリブンで個性的なサービスを生み出していました。他にもmiyagawaさんなど、個人で世界的に使われるようなOSSを開発している人もいました。書籍「ハッカーと画家」で描かれるような、ハッカーが個人技で大企業を出し抜く痛快さがありました。 そのように、WebサービスにせよOSSにせよ、同年代のハッカーが自分の技術でイノベーションを起こし、世の中に影響を及ぼしていることに羨望の眼差しを向けていたのです。 サブカル的な空気感も好ましく思っていました。西海岸のコンピュータ文化はヒッピーカルチャーの影響を受けていたのは間違いないでしょう。当時の

前のエントリの続きです。思ってた以上に反響があったので、主語を控えることも検討しましたがこのまま行きます。前回同様、すでにMicroservicesでバリバリやっている人は読む必要ないと思います。 前回の最後にMicroservices時代になると、開発者がこれまで以上に監視に取り組んでいく必要があると言う話を書きました。多少重複するところもありますが、その辺りから話を始めます。 モノリシック世界観での監視 アプリケーション監視の浸透 Microservices時代の監視設計 開発者自身が監視する どう監視するか メトリクス設計 The Four Golden Signals USEメソッド REDメソッド USEとREDの補完関係 The Four Golden Signalsの素晴らしさ 例: ある認証コンポーネントの監視設計 まとめ モノリシック世界観での監視 Webサービスの構成が

エンジニアに限らず、BlogやTwitter、OSS、登壇など、対外発信力がキャリアにおける強力な付加価値になることは知られるようになりました。 英語力がそうであるように、発信力は必ずしも必須スキルではありません。英語ができなくても活躍しているエンジニアはいくらでもいます。同時に英語がそうであるように発信力が有力な付加価値をもたらすスキルであることは事実です。 私自身、発信力が強みになっている分バイアスがあるので、あまりそのスキルの価値を過大評価して他人に押し付けるようなことはしたくありません。それに、エンジニアだったら発信力などではなく、純粋な技術力で評価されたいよな、という青臭い気持ちもまだどこかにあります。 ですから、全員が発信すべきだとは考えません。ただ、対外発信に興味を持っている人は後押しはしたいし、そういう人が増えてほしいとは強く思っています。なぜならば、それが単純に楽しいから

speakerdeck.com 去年の10月にAWS DevDayに招待いただいて話した資料を今更公開します。 現状のシステムを説明するとともに、僕が入社後取り組んだ細かい取り組みについての内容になっています。現状の規模の雰囲気を掴んでもらうために最初の方は製品や会社説明っぽくなっていますがご容赦ください。 Nature Remoは所謂IoTサービスで、システムの裏側が気になる人も多いんじゃないかと思いますが、実は結構オーソドックスなWebシステムで動いています。メインは、Amazon ECS上で動くGoのWebシステムで、IoTデバイスであるNature Remoの通信もWeb Socketが用いられています。 IoTの世界ではありますが、実は普通のWeb技術が使われているのが面白いポイントです。 エンジニア積極採用中です! Natureではこのシステムをより良くしてくれる「普通の」We

エンジニア大好き「推測するな、計測せよ」。これは、Plan 9, UTF-8やGoの作者としても知られる、Rob Pike氏の Rob Pikes's 5 Rules of ProgrammingのRule 3.に由来すると認識している。以下に原文を引用する。 Rule 3. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. Rob Pike's 5 Rules of Programming 訳すと以下のようになる。 「計測せよ。計測するまでチューニングをするな、そしてそこが支配的じゃないならチューニングするな。」 要は「チューニングする前に計測せよ」という主張で「推測」と言う言葉は出てこない。なの

この記事は、ex-KAYAC Advent Calendar 2018の17日目の記事です。 Songmuです。現在は、はてなと言う会社でチーフエンジニアとしてエンジニア採用等に関わりながら、プロダクトとしてはMackerelというサービスのプロダクトマネージャーを務めています。 カヤックには2011年から2014年まで在籍し、ソーシャルゲーム開発・運用のリードエンジニアを務めていました。主に甲子園シリーズのガラケー向けのタイトル運用が一番長く関わった仕事です。姫騎士と最後の百竜戦争というタイトルに企画から関わり、リリースから初期運用まで携わったのが最後の仕事でした。 カヤックは僕にとっては紆余曲折のキャリアを経て、30歳にしてやっと入った初めてのWeb企業です。複数台構成のWebシステムをスケーラブルにSPOF少なく構築し、それなりのトラフィックをさばきながら開発・運用する経験は初めてで

このエントリーははてなディレクターアドベントカレンダー2016の15日目の記事です。また、このエントリは先日の はてなエンジニアセミナー #7 でお話したことを、書き起こしたものでもあります。 Mackerel というサーバー監視・管理SaaSの開発チームのディレクターを務めている id:Songmu です。はてなのチーフエンジニアも兼務しています。 これまでの経歴としては、中国でITベンチャーの立ち上げに関わったり、その後語学学校で営業兼システム担当、SIer、Web企業でソーシャルゲームのリードエンジニアなどの経験を経て、2年ほど前にはてなに入社しました。 現在兼務している、ディレクターとチーフエンジニアという職位は、一般の企業では両方共課長格くらいで、W課長みたいな社内では珍しい立ち位置です。 Mackerelのディレクターとしては、プロダクトマネージャーとスクラムマスター的なことを

私たちは、スタートアップの実践、あるいはスタートアップに関わる活動を通じて、より良い突破口を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。 組織よりもプロダクトを 成熟よりも成長を 分析よりも行動を スマートさよりも泥臭さを 冗長性よりもユニークさを 真面目さよりも面白さを 価値とする。すなわち、左記の事柄に価値があることを認めながらも、私たちは右記の事柄に、より価値をおく。 このマニフェストについて 主語が大きい! おわかりかと思いますが、これは「アジャイルソフトウェア開発宣言」のオマージュです。ほかにも、「やっていき宣言」などありますね。 先日、スタートアップのCTOになりましたが、僕自身まだまだ覚悟が足りないことを重々自覚しているので、自分を叱咤するためにも書き出してみた。採用を含め、今後組織を成長させていく中で、果たしてスタートアップとはどういうものなのか、

お題「エンジニア立ち居振舞い」 僕の前職のカヤックという会社では「コミュニケーションは取ったもん勝ち」という言葉が一時期よく使われていて、これは実際そのとおりだな、と思う。 僕自身はおおよそ社交的な人間ではないけど、以前から仕事をする上で自分からコミュニケーションを取りに行くことは意識している。意識してるけど、残念ながらできないこともあるのだけど。だから、ちゃんとできているかは定期的に自問している。 「コミュニケーションを取りに行く」とは例えば以下のようなこと。 不明確な点があったら自分からステークホルダーに聞きに行く 仕様を調整しに行く 偉い人に直接掛け合う 新しく入った人に声をかけに行く 話しかけづらいなと思われていそうな時にこちらから話に行く 声をかけることには誰しも勇気がいる。エンジニアは得てして怖がられがちというのもある。だからこそ自分から行くことを心がけている。声をかけたら大体

少し前にエンジニア採用に携わっていた頃は、XのDMなどでスカウトを送っていた。丁寧に文面を考えていたので、一通に大体15~30分かかっていた。それもあって、スカウト返信率は70%を超えていた。そういう僕のスカウト文を見て「これはAIでは書けない文章だ」と誉めてくれる同僚もいた。 実際、僕はスカウト文を作るときに最近の生成AIは使っていなかった。ただ、生成AIでスカウト文をいい感じに書いてもらうことも全然できるだろう。やっている人もいるだろうし、それは全く否定しない。単に、僕の個人的なポリシーとして、文章を書くときには「まだ」生成AIを使わないようにしているというだけだ。 別に、未来永劫使いたくないという話ではない。今はこの新しい道具を自分に馴染ませていくフェーズなのだ。実際、文章を書く以外のリサーチや、ちょっとしたコードや画像の生成に生成AIを使うことはもはや日常になった。 それでもなお、

このエントリはMackerel Advent Calendar 2021の3日目の記事です。 最初にお断りしておくと、この話は4年以上前の昔話であり、私は既にMackerelチーム、はてな社から離れています。なので、ここで書くミッション・ビジョン・バリュー(MVV)はあくまで当時のものであり、今は別の形になっているでしょう。ですので、ここで書く話はただの昔話です。現在のMackerelに変に影響を与えたくはないと思っていることを予め書いておきます。 以前MVVの話を友人とした時に興味深く聞いてもらい、ユニークだとも言ってもらえたことがあったので、それらを決める過程の話や、浸透させようとした方法を書いてみるのも誰かの参考になるかもしれないと思い、これを書いています。 プロダクトマネージャー就任とMVV 私はMackerelのプロダクトマネージャーになった最初の頃に、MVVの策定に取り組みまし