読者です 読者をやめる 読者になる 読者になる

たった10年前の某IT企業でのこと

年末だからなのかはわからないですが、何か最近闇エントリが氾濫している気がするので自分も書いてみる。10年前にプログラマとしてのキャリアをスタートさせたわけですが、当時入社した独立系の中小SIer企業(D社とよぶことにする)についての話し。

※あらかじめお断りしておくとSIerディスるつもりはまったくなく、10年前に入った会社がひどいSIerだったというだけです。これから会社選びをするという方はSIerというだけで色眼鏡をかけないでいただきたい。

雑用

基本的に100%開発に専念できるという環境にはない。特に新人には様々な雑用が降ってくる。記憶している限り、こなした雑用は以下のようなもの。

  • 電話対応
  • 来客対応、🍵出し
  • バイク便手配
  • 取引先の新事務所オープンによる花の手配
  • 朝の掃除。ちなみにテラスがあってタバコエリアになってるのだが、吸わない人が吸い殻を扱うのがつらい。
  • オフィスの引っ越しでの荷物の搬入(引っ越しは全てセルフサービス)

朝礼

普段は私服勤務なのだが、月曜日だけ朝礼があるという理由で自社オフィスにも関わらず何故かスーツ勤務が義務付けられた。入った1年目はなんか緩めだった気がするが、2年目にガッと人が増えた段階で形式ばった宗教感あるものに変貌を遂げた。その朝礼のコンテンツはこのようなもの。

  • 社長のありがたいお話(15〜30分)くらいを起立で拝聴する
  • 社訓?的なものが額に掲示され、それの全員での唱和
  • 持ち回りで社員がスピーチをする(3分だったかな?)

宗教ですね。ちなみに偉い人と帰りの電車で一緒になったとき、国政選挙で某K党への投票を勧められたことがある。ああ、ソッチの人でしたか。おお、もう・・・。

チャットツール無し

SkypeMSN Messengerみたいなチャットツールは当時も存在していたが、使用は許されていなかった。さらっと聞いたことがあるが、セキュリティガー、情報流出ガーの一点張りであった。 つまり、開発でのコミュニケーションは全て口頭と共有サーバ(NAS)だけで行われていた。

バージョン管理ツールはあったが、何故かVSS(Visual Source Safe)でソースコードを完全にロックするタイプのものだったため、先輩社員のとこにいって「そのソース、離してもらえないでしょうか?」みたいなお伺いを立てる必要があった。Gitは偉大というしかない。

資格取得を求められる

最近の潮流はわからないが10年前は未経験OKみたいな中小のIT企業がかなりあって、その中でよくあったのが◯◯の資格を取得してもらって技術者としての下地をつけてもらいます的なやつ。 D社もこのパターンで、入社から1ヶ月でJavaの資格であるSJC-P(現OJC-P)の取得を求められた。取れなかったらペナルティとかは無かったと思うが、所謂人売による人月商売を生業にしている会社だったので、ただの未経験だとスキルシートだけで弾かれるケースも多いので、Java案件においてはSJC-P持っていればある程度案件には困らないだろうという算段だったかと思われる。

資格取得のプロセスだが、基本的にOJT的なものや既存社員が教えてくれるということはほとんどなく、よくわからない教材での座学である。メモ帳でJava書いてた記憶がある。短期の詰め込み型ではあるが自分は無事1ヶ月で合格することができた。ちなみにSJC-Pの受験費用は25,000円くらいだったと記憶しているが、合格すれば経費として落とせるが不合格の場合は自腹という当時の薄給な状況においては絶望を感じざるを得なかった。

多産多死型採用

とにかく未経験で都合のよくコントロールできそうな人材をかき集めていた気がする。感覚的には5人採用して1人うまく育てばよいくらいの感じじゃないだろうか。同じ時期に入った社員の中にはデスマに耐えかねて突然の蒸発をキメられた方や、入社2日目に来なかった方もおられた。

正直ネガティブな要素の方が強いと思うが、未経験でもOKみたいな謳い文句はIT業界で何とか手に職をつけたいと思っている人にとっての人参ワードであった。今からすると本当にしょーもない会社で、現代においてはさっさと滅びるべきと思っているが、生き残った少数派である立場からすると多少の感謝もある。ただ、圧倒的に多くの人材を使い潰してきている事実は変わらないのでやっぱり滅びるべきですね。

トラブル

このような会社だったため、生々しいトラブルの最前線に遭遇したことがある。

どうやら何か取引先とトラブルがあったらしく、取引先の偉い人が会社に乗り込んできたことがあった。簡単に言うと、激高したD社社長と取引先の偉い人が怒鳴り散らしまくって完全にヤクザの喧嘩状態に陥ったのでついには警察出動した。ヤバい業界に入ってしまったと思ったが、業界の中のヤバいクラスタに入っただけと気付くのにそう時間はかからなかった。

改めて振り返って

ヤバい。

stackimpactでGoアプリケーションのメトリクスを可視化する

Go metrics tool

stackimpact というサービスはご存知でしょうか。

f:id:a-yamada:20161118130926p:plain

このサービスは何かと言うと、Goアプリケーションのメトリクスを可視化するためのサービスです。競合はNewRelicあたりでしょうかね(最近NewRelicでもGoが正式にサポートされましたが)。

とりあえず使ってみましょう。

エージェントのキーを取得する

stackimpactにサインアップすると、エージェントのアプリケーションキーが発行されます。Configurationのページで後から参照もできるのでメモしておく必要は無し。

stackimpactのエージェントがGitHubに公開されています。これを go get とかで取得してきます。

github.com

以下のコードを対象のアプリケーションに仕込むだけです。

import (
    "github.com/stackimpact/stackimpact-go"
)

func main() {
    agent := stackimpact.NewAgent()
    agent.Configure("your_stackimpact_key", "MyGoApp")
}

実際に利用するには、環境変数等でエージェントのキーを設定できるようにして、キーが設定されていればエージェントを実行するみたいな感じの実装にするとよいでしょう。

動かしてみる

stackimpactが仕込まれたGoアプリケーションを実際に動かしてみます。アプリケーションの起動から1分くらいでstackimpactの方にグラフが表示されるようになります。

Healthの項目では、CPU/Memory/Garbase collection/Runtimeといったグラフが見ることができます。

f:id:a-yamada:20161118133746p:plain

重要なのはHealthよりもHot spotsの項目で、例えばメモリであればどこの処理で大きめのアロケートが走ったかとかがわかったりします。

f:id:a-yamada:20161118135226p:plain

この例ではstackimpactのreporterで大きめのアロケートが走った模様w

その他、チャネルのwait timeやsystem wait, lock waitが確認できますね。

また、HTTP Handlersでリクエスト時間上位のもののコールスタックを確認することができます。

f:id:a-yamada:20161118134203p:plain

あんまりスタックを深掘りしちゃうとウチの情報が見えてしまうのでここまでにしておきますが、ステップ毎の所要時間がわかるので便利。

プラン

stackimpactは無料で利用することが出来ますが、エージェントに制限があってフリープランだと最大5エージェントまでとなってます。

有料プランについてはPro subscription plansのページを参照されたい。エージェント数やデータの保持期間で変わってくるようです。

エージェントという概念が重要で、ホスト単位ではないことを留意しておく必要があります。例えば、同一ホストに2つのstackimpactが仕込まれたGoのプロセスが稼働していれば、それは2エージェント消費ということになります。もちろん、Dockerコンテナで複数コンテナ起動しようが同じ。

まとめ

あまり知られてないサービスだけど、5エージェントまで無料だしサクッとボトルネック探したりするのに役立ちそうな感じ。

エンジニア立ち居振舞い(動画サービス開発者編)

エンジニア 動画 監視

お題「エンジニア立ち居振舞い」

TLを眺めていたらこんなのが流れてきたので乗ってみます。

blog.hatena.ne.jp

メトリクス・パフォーマンスの監視

mackerel

EC2やRDSといったAWSリソースの監視や、サービスの外形監視等にmackerelを利用しています。もちろん閾値を超えればSlackにalertが飛んで来るようにもなってますけど、定期的に目視でも見て異常の兆候が無いかをチェックします。

mackerel.io

kibana + Elasticsearch

アクセスログやアプリケーションログはfluentdからElasticsearchに転送し、Kibanaで可視化しています。APIのTime Takenをログに出すようにして、Kibanaでグラフで可視化+ダッシュボード化でどのAPIにネックがあるか、リクエストの多いAPIはどれかを特定し、チューニングの飯の種にしています。

Speedcurve

自分の領域はどっちらかというサーバ+バックエンドよりですけど、バックエンドの問題は当然フロントエンドにも影響するのでSpeedcurveもちょくちょく見るようにしてます。

speedcurve.com

Start Render、Speed Index、Visually Complete等の総評的な指標はもちろんのこと、その他の詳細指標もまとめて見れるのでかなり重宝。リリースのタイミングでタグを打てるので、どのリリースによって指標がどう変化したのかが一目瞭然でかなり良いですね。

f:id:a-yamada:20161111131803p:plain

FRESH!ではDockerイメージのタグを日付+連番で打ってるのでこのような感じで見れます。

視聴の監視

動画サービスはかなり厄介で、各種メトリクスからだけではサービスの異常を検知しきれないこともしばしば。

というわけで、会社でも自宅でも常にiPadを側に置いていて異常があればすぐに気付けるようにしてます。

f:id:a-yamada:20161111132033j:plain

もちろんこのままで良いわけないので、この辺の検知の仕組みを先々は考えていかなければならないところ。

積極アップデート過激派

自分の場合はiOSユーザーなので、最新のiOSへのアップデートが来たらすぐアップデートしてアプリの挙動を確認してます。もちろん社内のiOSエンジニアはiOSのβ版での動作確認をしてますが、実際に正式リリース版にアップデートして挙動を確認した方がいいでしょう。

まあ実際はアップデートによって全然関係ない他のアプリが巻き込まれて困ることの方が多いですけどね。

Twitter監視

会社ではTwitter監視用のモニターを用意して、TweetDeck で常にツイートを垂れ流してます。

f:id:a-yamada:20161111132615p:plain

サービスのハッシュタグは基本的に番組シェアで利用されることが多いので、エゴサーチも活用して気になる挙動をツイートからキャッチアップしたりということをしてたりします。

まとめ

動画サービスエンジニアの悲哀が少しでもおわかり頂ければ幸いであります。