ドリコムを退職しました……弟子が | 外道父の匠
世間の流れに沿って、一度、退職エントリを書いてみたかったんですけど、まだちょっと退職しそうにないんで、倒置法で我慢してみました。 本人には「退職エントリ書くね！」と去り際に伝えてありますが、センシティブなカテゴリですから、企業・個人事情に基づくものというよりは、身近な人間が退職したという出来事に対する感想的なものとなります。 ザッと振り返って 前に書いた、「新卒インフラエンジニアを育成した話」で地獄を見せようと試みて、いまいち業火で焼き尽くせず耐え切ったアノ弟子です。二年が経過し、中小規模のサービスを専任で4～5個担当するまで至っていたので、当人の努力と成果は十分であったのかと思います。 他にも、AWS関連や、インフラのアーキテクチャなどは、私と共に進めたり、時には率先して案を出したりもしてくれていたので、中盤からは弟子というよりは普通に共同作業者という立ち位置でした。例えば「現代ITイン
新卒インフラエンジニアを育成した話 | 外道父の匠
お久しぶりでございます。諸事情によって半年近くも息を潜めていましたが、また継続的なアウトプットをしていきたいと思います。あうとぷっとあうとぷっと。 昨年からAWSに触り始めて、少しずつ研究して、今年から本番運用を開始できています。なので、そっち方面が多くなりそうなのですが、その一発目として昨年にAWSを軸に新卒インフラエンジニアを育成してみた話を書いてみます。 経緯 ウチでは一般的な新卒採用を行っています。内定が出て、入社後はエンジニアも一定期間の研修を受けて、そして配属されることになっています。 私は稀に、キャリアプランによっては内定した段階の子との面談を組まされるのですが、その時点でインフラエンジニアになるという断固たる決意を持っていて、研修の段階に入っても意志は変わらなかった野郎がいたのでインフラ部隊に入れることにしました。しましたといっても普通は、配属は本人の希望以外に人事部判断や
サービス品質の改善効率を高める仕組み | 外道父の匠
最近うぇぶ業界では、開発効率や構築効率を求める動きが活発のように見受けられますが、ここで改善効率について手を伸ばしてみましょう。 改善効率とは、開発後期やサービス開始後の運用フェーズにおいて、クソコードやクソクエリ、データの蓄積によるレスポンスの悪化などを、自動的に検知し、開発者にオラオラ改修をプッシュするための仕組みのことでございます。 はじめに ここで紹介する内容はドリコムで実際に運用しているものですが、別にドヤ顔するようなものではなく、中規模以上の企業ならば似たようなことやそれ以上のことをやっているであろう、至極当然な内容です。それでも、それなりに種類が増えてきたことと、それなりの効果を得られていることが実感できているため、いったんまとめてみようと思った次第です。 ウチのサービスのサーバーサイドは Ruby on Rails + MySQL が基本なので、その対策手法になります。WE
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
