実録：「えっ、このシステム何ですか？」から始まる小さな引継ぎのおはなし。

はじめに

みなさまこんにちは。なんとか生き延びております、たかのです。

いきなり本題ですが、事業を長く続けていると、サービスの中核のシステムは肥大化します。 複雑さが増せば、理解も運用も大変になってきます。

そんな複雑さを回避するために、小さい単位で機能を分割し、別システムに切り出すことはよくあることです。 クラウドワークスにも、中核のシステムを支える小さなシステムがたくさんあります。

生きているからこそ、お世話がつづくのです

システムは生き物です。（そうは思えないかもしれませんが、そんなものと思ってみてください！*1）

稼働はしていても拡張や整理の判断ができず、「属人化」どころかその進化系で、作った人が退職して詳しい人が誰もいなくなってしまったもの。 そんな状態を、わたしたちの職場では「無人化」と呼んでいたりします。

こうした状況は望ましくないので、メンテナンスを仕組み化し、チームで分担して取り組むようにしています。

さて、わたしたちのチームも、この「無人化」対応のタスクを1つ担当することとなりました。 その際のあれこれや学びについて、わたしの「 余技 」をふまえてお伝えします。

見積もりするよ！

*1:お母さんが言うんだから間違いありません！

Amazon LinuxのEOLに伴いバッチをサーバレス化しFargateに移行した話

はじめまして、2020年3月に中途入社したSREチームの @bayashiok です。

今回は入社後、Fargateでサーバレスバッチ基盤を構築した話を書いていきます。

目次

経緯

日々のSREチームのタスクの中で、EOLとなるソフトウェアの状況を定期的にチェックしているのですが、今回 Amazon Linuxが2020 年 12 月 31 日にEOLを迎えるということで、Amazon Linux上に設置されているシステムを移行する必要がありました。

Amazon Linux2に移行するという案もあるのですが、このままでは負債(後述記載)が残ってしまうためAmazon Linux上に置いてあるバッチの整理と移行バッチのFargate化を行いました。

Fargateを選んだ理由

Fargate化することのメリットは次のようなものがあげられます。

クラウドワークスを退職します。

お世話になったオフィス

こんにちは、@ysk_118 です。
実は2020/06/30をもって退職することになりました。
2015/05/18に入社していますので5年とちょっと在籍していたことになります。

時系列とKPTでこの5年を振り返ります。

whoami

この5年で非常に多くのことに携わりましたので、まず軽くやってきたことを振り返りながら何者なのか知っていただけたらと思います。

• 2015/05〜2016/03: 開発Div. エンジニア
• 2016/04〜2017/02: プロダクトDiv. 新規事業開発グループ チームリーダー
• 2017/02〜2018/03: プロダクトDiv. エンジニア -> スクラムマスター -> プロダクトオーナー
• 2018/04〜2019/04: プロダクトDiv. エンジニアリング部 部長
• 2019/05〜2020/06: 執行役員, エンジニアリングDiv. GM, 人事兼務¹

クラウドワークスに入社した当時は新卒3年目でまだ経験的にも浅く、エンジニアとしてしっかりキャリアを積んでいきたいという一心でいろいろな会社を受けていたところ、運良く拾ってもらえたので非常にうれしかったです。

そこから2年ほどエンジニアとして様々なプロジェクトに関わり、その後スクラムマスターやプロダクトオーナーとしてプロダクトや組織そのものへアプローチを1年ほど。さらにその後組織全体をみていくポジションに手をあげ、マネージャーや執行役員として会社全体の中でのエンジニアリングを考える役割を2年ほどやってきました。

こうしてみると自分で手を動かすよりもマネジメント寄りのことをしている時間のほうが若干上回っていそうです。当初の目的であったエンジニアとしてのキャリアを突き詰めるよりかはなんだかんだジェネラリストを極めた結果になってしまいましたw

---

1. Div.=Division(部署) GM=General Manager(部門責任者)↩

Rollbar による快適通知生活 (フロントエンド編)

こんにちは、エンジニアの Bugfire です。

自分の前の記事 でも Rollbar について書きましたが、今回はフロントエンド編です。

無法地帯

バックエンド(Rails)では、Rollbar による通知は便利に活用されており、対応したりみなかったことにしていたわけですが、フロントエンドでは以下の状況にありました。

• あまりにもエラーが多い
• エラーが多すぎて課金がすごいことになるのでかなり厳しめの RateLimit をかけていた
• エラーが多すぎて slack 通知していない
• 結局エラーを誰もみていない
• SourceMap が登録されていないので、いざ登録されたエラーをみても分析が難しい

問題は、エラーが多すぎる件と SourceMap がないの二点です。それぞれ対応していきます。

目次

イニシエのコードをモダンJS化

こんにちは。D&Aチームです。

クラウドワークスではユーザーの皆様により良い体験をしていただけるよう、クラウドワークス 安心安全宣言の取り組みを進めています！

そんな中、私たちのチームでは、ほぼ初めてのフロントエンドの開発に関わることになりました。 新規での開発ではなく、既存の実装からの更新という形となるのですが、それは古の時代のCoffeeScriptで書かれたものでした。

今回のブログはフロントエンドモダン化までの流れについて書いていこうと思います。

目次