スタートアップにJOINして1年(近く)経ちました

@gaooh

COMPANY

動画制作のクラウドプラットフォーム

COMPANY

WHO ARE YOU？@gaooh

リードエンジニアさせてもらってます

猫とビールとRubyが好きです。

渋谷や高田馬場でRubyをかいてたり、新宿や六本木でPerl

書いてたり、Objective-C/Javaとかもあるけど、まぁキャリアはいろいろ

MAIN ISSUE

スタートアップにJOINして約 1年

心が折れることなく目の前のサービス開発と泥臭い改善と戦い続ける武器を磨き続けるためにしてきたこと

I'M CAREFUL

モダンな感じで維持し続ける

開発速度を低下される要因をなるべく取り除く

DevOpsによるOpsの見える化

MODERN？

より速く走れる高速道路

more better を考える

1ヶ月ごとの開発振り返り

変化に寛容な雰囲気作り

DEVELOPMENT SPEED

デプロイの最適化

CIのスピード

深夜に遅いテストをリストアップ

車輪の再発明をなくす

シンプルだけどコードレビュー

DEVOPS

インフラエンジニアはいません

コードに落とせない心温まる手作業

github issueでレビューと共有を心がける

きっと自動化するときに役に立つ

最初からこうではなかった！

JOIN ～ THREE MONTHSバックアップ…..たぶん….たぶん….とってる….えっと xxxxさーん

SPOF ？ SLA？ なにそれおいしいの？

デプロイがたまに原因不明で失敗するんですけど……

サービス開発優先にしてたらいろいろまずいことが……

片手間でたてたwordpressが定期的に落ちるですが…….

CALM DOWN

当時: エンジニア4人

サービス開発は当然やり続ける必要がある

B2Bなので一気にアクセスが増えることはない

扱うファイルが一般的なwebサービスに比べると巨大

データの保全は気をつけないと

PREMISE

大規模にいろいろ整備するお金も暇もない

サービスあたってアクセス爆発した！みたいな嬉しい悲鳴はではない

目をつぶるところはつぶる！

クリティカルなところを優先順位付けしてやるしかない

FIRST

SPOFを整理し、SLAを決める

諦める場所を決める

お金と時間は有限

エンジニア以外にも説明ができる

サーバは気合いでどうこうできない

CONCURRENT

バックアップなどの情報整理

RDSのバックアップ保持期間

メンテナンスウィンドウの時間調整

S3のバージョニング

ログの記録

START UP

先回りの運用はやりきれない

せめて何かあったときになんとななる下地だけ

リリース後1年近く経つとほころびがではじめるころ

地味な小石につまづき始めるころ

CONCRETE EXAMPLE INDEX

安心してデプロイできる環境

スタートアップは何度打席にたつかが勝負

サービス開発を優先したがための問題点を除去

それ以外の小石拾い

例1

DEPLOY

deploy flow をうまく使えてない

rollback をしたことがないのでなんか怖い

deploy サーバからしか deployできない

たまに失敗する

CAUSE

育ってきた ( 過去の 環境の違い

「こうしたほうが楽だよ」「こんな方法はあるよ」はJOIN

したノリでやるのがいい

人間は不便なものでも慣れると変化を面倒と思うようになる

CURRENT

MORE？

Docker？ Elastic Beanstalk？

サービスの規模を考えながら一歩一歩

変えようとすることにつねに前向きであることが大事

DOCUMENT PR

コードに落とせない開発ポリシー、ルール

もっとよりよい方法が思いついたとき誰でも変更できるように

誰かが一人がえいときめることも時には大事だけれど、変えたいと思った人が変えられる環境も大事

例2

SPEED OR QUALITY

隙のないアーキテクチャー、大規模でも耐えれる設計

現実は…..

自分も生み出すことはあるので誰も責められない

大事なのは目を背けないこと！

賢明なるみなさんに質問です

3G越えのファイルをRAILSを通してアップロードしたらどうなるとおもいますか？

インスタンスタイプをあげてのりきろう！

お、おう….

EXTREME EXAMPLE

極端な例ですが、こういうのの小さいバージョンはよくある

技術的負債というにはおこがましいやつ

目の前の開発コスト？長期的なコスト？の天秤

コツコツと直しましょう。

既存の仕組みを捨てることに前向きになりましょう。

FACTS

巨人の肩に乗りました

S3へ直接Upload, Job管理はSQS, 処理通知はSNS

START UP ON AWSサービス開発に注力したいなら使い倒す覚悟を

片手間だとけっこう活かしきれない部分があるよ

VPCの設計とか迂闊に手をだすと変なことに….

巨人の肩にのるための準備運動は必要

ローカルの開発環境のこともかんがえないとリリース後トラブルの元

CURRENT

OTHER

ログが放置されてたのでfluentdいれたり

メンテ画面を出せるようにしたり

監視まわりをみなおしたり

開発効率系gemをいれまくったり

SUMMARY

スタートアップにJOINして約 1年で、心が折れることなく目の前のサービス開発と泥臭い改善と戦い続ける武器を磨き続けるために大事だとおもったこと

つねに変わり続けられる勇気

めげない心

お金と時間を最適なことに使う意識

泥臭いことも正直あります….

でも一緒に戦いたい人を募集しています！