最近、イベントレポート系のエントリばかりなきがします。先日こちらのイベントで話してきました。 第21回 AWS User Group - Japan 東京勉強会(一般枠) - JAWS-UG東京支部 | Doorkeeper nanapi.jpというサービス自体は今現在はオンプレミス環境で動いています。その他のアンサーや、ignitionといった新サービスがAWSで稼働しているので、そのあたりの内容です。 一緒に登壇する方々がすごい方ばかりでどんな内容発表しようかなぁと悩んだのですが、結局ふつうの発表です。まぁ５分の発表時間だったので、そこまで多くのことは話せませんね。 他社の事例をいろいろ見ることができて刺激をうけることができました。もうちょっといろいろと実験して、面白い構成にチャレンジしてみたいものです。

AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ

情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で