「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ
先日から個人的にフルサイクル開発のことを色々と調べる機会があり、Qiitaに以下の記事を書いたのだが、
この中でほんの少し触れたVOYAGE GROUPの例について、情報源である「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」に書かれているその考えや文化については色々と興味深かったため、もう少し書き留めておきたい。
フルサイクル開発の文化
第2章 「Zucks - フルサイクル開発者の文化」 ではアドネットワークやDSPを提供するZucks社の開発チームの文化について書かれている。 VOYAGE GROUPのフルサイクル開発というのは主にこのZucks社の文化のことを言っている。
Zucks社のフルサイクル開発者
「ビジネスアイディアからお客さんに届くまで」を1つのサイクルとみて、それを全て一人の技術者でもやれるようにしよう、というのがフルサイクル開発者のイメージです。お客さんに届いたものから更にビジネスアイディアが生まれ、また別のサイクルが始まります。
とのことで、開発者のみならずエンジニア全般にフルサイクルを意識して欲しいため、「フルサイクルエンジニア」とも呼んでいるとのこと。
実際にエンジニアに求められる業務範囲のイメージとしては先のQiitaの記事でも書いたが、
全部を作れる必要はないけれど、その代わりビジネス的要件を整理するところから一人でできること。
なおフルスタックである必要がないのは以下のように書かれており、
すでに動いている仕組みについては、その使い方くらいを知っていれば、ビジネスアイディアをお客さんに届けるのに十分でしょう
これだけ読むと小さい改修に限られるイメージをしてしまうが、これは逆に「ビジネス要件の整理から」という上流工程に踏み込む方がフルサイクル開発者としてより重要になるということと理解している。
このことは、Zucks社のエンジニアの求人票 に 「業務を遂行する際、大切にしている1つに、一人のエンジニアが誰かに待たされずに開発を行う点があります。誰かが仕様を決めて、それをただ実装するだけのエンジニアはチームにいません。」 と書いてあることからも見て取れる。
ちなみに、この求人票の経緯について以下のnoteに綴られているので参考まで。
ジョイン初日にリリースする
求人票にも明記されているZucksの文化として、「ジョイン初日に必ず管理画面の機能をリリースする」というものがあるらしい。 かなりインパクトがあるが、これが如何に難しいか。
なぜ難しいか
どんなに軽微なissueをアサインするとしても、ぱっと思いつくだけでも
- オンボーディング、PCセットアップから該当issueにたどり着くまでの時間の早さ
- ツールのアカウント準備やアクセス等で躓くことがない
- そもそも必ず新人が初日クリアできるような適切なissueを整理している
このあたりがクリア出来ていないと絶対に初日では終わらないから。
初日リリースを可能にしている要素
この本の中ではその他にこれを可能にしている要素として以下を挙げている。
- 基本的にmasterブランチしかない
- 広告配信は本番環境でないと分からないことが多いことなども要因と思われる
- エンジニアの権限を分けていない(全員admin権限)
- これは一見「雑」と思われそうだが...
- 切り戻しできるかどうかを重要視
- 小さな変更でも安全に戻せない(破壊的変更)のであれば止める
- DB設計もきれいさより切り戻しが容易であることが優先(カラムを消さないなど)
とは言え
新人にとってはかなり大変な文化なのは間違いない。 広告業界経験者でも初日でそこまでやるのは難しいのに、広告業界が初めての人にとっては「そもそも何を言っているのか分からない」だろうから。
しかもトレーナーになる担当者がつきっきりでもなく「何かあったら聞いてくれ」という放置っぷり。
さらに、issueの内容からして簡単な修正だと思いきや、そのissueの背景などを営業にヒアリングするなどして理解した上で適切な修正方法を取っていないとPRで総ツッコミを受けるとか、レビューしたAさんとBさんで違うこと言ってたりとかして翻弄されるとかあるらしい。
(このトークイベントの中でそんなことを言っていた)
合わない人には全く合わない文化だと思うが、新人が初日でアウトプットを出せる、事業に貢献できる実感が持てるということにはとても価値があると思う。
ドキュメントレス文化
Zucksでは、他社で通常ドキュメント化されるような情報でも、全てGithubのissueだけで管理しているとのこと。
理由は以下。
- 一回でもドキュメントを書いてしまうと、そのドキュメントをメンテナンスし続ける作業が発生してしまう
- メンテナンスされないと新しい人が入ってきたとき、古いドキュメントを有効な情報だと思って参照してしまうことにもなる
- コードに一番近いところでドキュメント的な情報を管理しようと思ったらissueが最適だった
※ちなみに、まったくないと言っても監査目的等外部に出すために必要なドキュメント等はきちんと作っているとのこと(少し上に貼ったトークイベントの中で言っていた)。
情報が欲しいときはどうするか
- まずGithubのissueを全文検索(全員この癖をつけている)
- 探しても見つからない情報は、人に聞くか、コードを見るか
- 最終的には動いているコードが正義
- 何かドキュメントが見つかってもそれは当時のスナップショットなので基本的に「ドキュメントは更新されていない」前提
気になったこと
- 動いているコードが読みにくい、意図がわかりにくいためにまずリファクタリングから始めて複数人の認識を合わせることから始めるというケースが結構多いらしい
コードレベルでない情報もissueコメントで追う必要がある
- issueをたどって全ての議論を追う必要はどこまであるのか
- issueコメントの議論をたどると結論が変わっているケースもある
- (これはこの文化の辛い側面として触れられてはいる)
全体の俯瞰、アーキテクチャなどを伝えるのは都度ホワイトボードに集まって説明するなどでカバー
- これは面倒くさくないのか... オンボーディングのコストがめっちゃ高い気がする。。
- これがあるのに初日リリース出来ているのには矛盾すら感じる。
このあたりを見ると特に新人向けにはお互いの伝達コストが高い気しかしないので、正直いってあまり納得感はなかった。 とは言え、だいたいどこの現場でも経緯が分からんというケースの方が圧倒的に多い気がするので、それを考えるとこう振り切ることのメリットの方が大きい、ということだと思う。
なお、新人向けにシステムのことを理解してもらう際には、まずは管理画面を一回触ってもらうことで流れと項目が理解できるので、それとセットで動いているコードを説明するなどして全体像理解のスタート地点に立ってもらうとのこと。これは理解できる。
その他印象に残ったところ
SRE部門の解散の背景
(第1章 「fluct - 広告配信の舞台裏の技術者たち」より)
SSPを運用するfluct社で、2019年11月にもともとあったSRE部門を解散し開発部門に統合。その背景としてこんな理由があった。
- だんだん開発チームからSREチームに「依頼」するケースが増えていた
- DevとOpsが分かれていることは悪くないが、本来は同じ目的を共有するチーム間で「依頼」が発生するのは本意ではない
ビジネスと一緒に開発する
(第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より)
就活支援サービスを展開するサポーターズ社では「ビジネス側から言われたものをそのまま作ることはしない」姿勢を明言している。
- かつては社内受託のような形で「この画面をこういうふうに作ってください」という、アウトプットが規定された「依頼」が普通だった
- 今はそのような来た場合は「なんで?」と即座に返す
- 「なぜ」を聞いた上で当初の提案よりもコストのかかる実装(理想)を提案することもある
- 今すぐ結果だけ欲しい人にとっては「いまはそれは良いから、すぐにできることだけ話してくれ」と感じる
- 「ちょっとしたお願いを相談しただけなのに、なんでこんな大きな話にされて、いっぱい話さないといけないんだろう」
これは非常に「べき論」を地で行っているが、ビジネスの方が立場の強い会社だと開発側が負けてしまうし、開発側が強い場合はビジネス側が「開発は相談に乗ってくれない」と不満を漏らして二度と相談に来ないという結果を生みやすいので、如何に日々コミュニケーションを濃密に取ってお互いを理解しているかというのが伺えるエピソードだった。
ちなみに、このような相談の場合にケンカにならないために押さえておくべきポイントを言うなら、
- ビジネス側:背景をきちんと伝える、結果を急ぎすぎない(サクッと明日までに大体で良いから見積ほしい(でも上振れしないでねという圧)とか)
- 開発側:温度感を踏まえて聞く、むやみに話を大きくしない(エンジニアは「そもそも〜」で話を振り出しに戻して大きくする人が多い)
以上踏まえてお互いに落とし所を見つけることかなぁ、と自分の肌感覚では思っている。
依存ライブラリは週1で上げる
(第5章 「サポーターズ - 事業の成長を止めない手段としてのシステム刷新」より)
同じくサポーターズ社で、「ガーデニング」と称してフロントエンドやサーバーサイドの依存ライブラリを毎週最新化するという運用を行っているとのこと。
- 最新バージョンへの追随は一度やめると二度と復活できないので、1ヶ月ではなく1週間で実施
- 「ガーデニングガチャ」で当たった人が実施
- 週次で上げるのはマイナーな変更(既存コードの変更がないもの)のみ
- ライブラリを上げる作業自体はコード変更がなければ単純作業なので、ガーデニング作業そのものの大半はchangelogの確認
これは簡単そうにやっているようだが、実はすごいこと。そんなこまめに上げていたことないな...
最初の1,2回なんとか乗り越えれば、後はそれほど苦ではないのかな。
でもメジャーバージョンアップがあるとこのルーティーンとは別タスクでやらないといけないはずだから、そこは同じなのかな。
最後に
2章のことでたくさん書いてしまったため他の章の取り上げ方が雑になってしまったが、 他にもレガシーのシステムといかに付き合っていくか、改修とリプレースの判断はどうやって行うのか、など、外から見ると楽しそうにやっているWeb系企業の現場で直面する決して華やかではない、むしろ泥臭さしかない課題に対する取り組み方などについても臨場感の伝わる記述がされたとても熱量の多い一冊だった。開発現場を経験しているエンジニアならきっとよくうなずく箇所や「いやこれはちょっと...」と賛否両論の独り言になること請け合いなので、是非一度手にとって頂きたい。
MacVim、Atomのvim-modeでEsc時にIMEをOFFにする方法
やり方を忘れてしまい新しいPCSierraでどうすんだっけ、と思い調べると、殆どが Karabinerによる設定方法ばかり。 最近Karabiner-Elementで対応できる様になったというのも見たのでいいんだけど、できればKarabiner無しでどうにかなんないかなぁと思ってたら、
Google日本語入力の設定だけでできるじゃん!
とっても助かりました。
このスケジュールで問題ないですか?
英文でスケジュール打診をするメールを書いているときに
「来週●月●●日以降に始めたいんだけど、問題ない?」と書こうとして、
”問題ない?”の部分をどう書こうかなぁ・・・と思い調べてみたところ、 ちょうどよいフレーズが紹介されていた。
うまくハマった(気がする)のでメモ。
Is there any way that you can adjust to this schedule?
(この予定に合わせて頂く事は可能ですか?)
このサイト、他にも使えそうな気になるフレーズが紹介されている気がするのでちょいちょい見てみよう。
Workflow Engines Night 参加メモ
開催日:2017/6/7
場所:DMM.comラボ 六本木オフィス
『StackStorm ワークフローエンジンによる運用コスト・リスク低減の取り組み』
株式会社DMM.comラボ 大山 裕泰氏
- StackStorm Contributor
- StackStorm AWS maintainer
digdagじゃなく別のWorkflowエンジンの話
運用者を悩ませる問題
- ユーザ(社内)との折衝コスト(口頭、チケット、メールで依頼)
- オペレーションコスト(多種多様なシステム環境、機器)
- オペミスのリスク、熟練オペレータしか触れない、教育コスト高い
- (確かに新人にLBは触らせないとかある…)
理想的な運用形態
- 定型運用のAPI化
- システムの適切な抽象化
- ×個別機器を操作する ◯操作して得たい結果を機械に教える
StackStormとは
- IFTTT x Workflow
- センサーが反応するイベントを受けて、一定のルールでActionを実行
- 例えばイベントに併せてリソースを増やす
- VMを作るだけの単体タスクじゃなく、VM作る→Provisioning→DNS登録→ELBにぶら下げるなど一連のタスク
Stackstormのある環境
- オペレーション用APIの提供
- 知っている人誰かに聞いたり、ドキュメントを漁ったり(用意したり)しなくてもStackStormを見れば分かる
- システムの抽象化(欲しい結果だけを指定する)
- 運用の自動化(個別のシステム状況に応じた対応を機械的に実施)
StackStormが実現するであろう未来
- 折衝業務を行うエンジニアの開放
- オペレータの運用・学習コストの逓減
- サービス運用リスクの削減
Q&A
- スケジュール実行はどのように?
- センサーからのイベントドリブンなので定期実行するのは可能
- 定期実行の際に重複実行を避けたい、どうする?
- 複数ノードに分散しているが、同じノードで同時に複数リクエスト来た場合のことは考慮されてない
参考資料
http://qiita.com/unchemist/items/0e6425396ba1a1e6b43c
『JenkinsからDigdagへ日次バッチを移行して幸せになるお話』
株式会社DMM.comラボ 鈴木 翔太氏
なぜDigdagなのか
- 多数の日次バッチ
- 所謂ETL
- これまではJenkinsで運用
- 問題
- Jenkins依存
- コードで管理できない
- 失敗時のリトライが大変
処理が時間依存
課題解決のためにワークフローエンジン導入を検討
選定ポイント
- ◎可用性
- ◎スケーラビリティ
- コード管理
- 失敗したタスクからリトライ可能
- 進捗確認ができるIF
構成
- Digdag2台、サーバ兼クライアント
- PostgreSQLサーバ2台(PgPool-II使って Active&Standby構成)
Workflow設計
プラグイン自作
- Slack通知を実現するdigdag-slackを作った
- SLAの通知に利用
チーム間連携(=システム間連携)
- あっちのシステムでファイルができたらこれを実行、みたいなの
- 時間に依存しない形で実行させたい
- mog(go製CLIツール)を作成し提供
- タスク名ベースでステータス確認可能に
- ワークフローのスタート&リトライも対応
- Github公開していない(が、渋ってるわけじゃないので公開します)
まとめ
- Jenkinsからの脱却
- 全てコード管理可能に
- コードで依存関係も表現
- バッチ失敗時のリトライも楽ちん
- mog CLIにより時間依存の処理を排除
『Treasure DataにおけるDigdagによる大規模データ処理の自動化とエラー処理』
トレジャーデータ株式会社 古橋 貞之
あまりメモ取らなかったけど詳しいレポートができてた
そもそもなぜDigdagを作ったか
- あらゆる手作業を自動化するため
- マルチクラウド、多数のミドルウェア、どんどん新しく出て来るのにエラーコードやハンドリング方法を全部覚えないといけないのか
- シェルで複数ジョブを順次実行するには上から並べることになるが、エラーハンドリングやモジュール化での再利用などに問題がある
デモ
- Treasuredata Workflowの画面で説明(ロゴが違う以外は一緒)
- Timelineにタスクの進捗状況、経過時間がビジュアルに見える(すごい)
- タスクを動的に増やせる
- ループタスクも書ける
使用事例紹介
- TD内で利用しているworkflowのユースケース紹介
LT『Digdagを使ってみて便利だったとこ、はまったとこ』
株式会社VASILY 塩崎 健弘
IQONを提供してる(若い女性ターゲットのファッショなプリ)
- クローラを開発してcronでジョブ管理
- 複数クローラのジョブを並列にcron定義
- 30分毎に実行
- でも30分で終わらなかったら?重複実行は?
- ハンドリングつらい
- Digdagは設定ファイルがシンプル
- AirflowやLuigiとくらべて自由度低い(高い自由度は不要、複雑なジョブができちゃうから)
- dockerサポート嬉しい
一時ディレクトリを切って実行してくれるので他のタスクからの影響を最小化できる
pythonのバージョンでハマった
- py>:オペレータはpythonコマンドを呼び出すが、OSによってバージョンが2で呼ばれる
- python3のdockerイメージを使用することで解決
ruby(rb)でも同じ問題が
一時ファイルの受け渡し
- 一時ディレクトを毎回ジョブ毎に切ってくれるのでまとめて読めない
- 一時ファイルはS3に書いて読み出し
Macにpython3開発環境を構築する (pyenv導入)
手元のMacbook airにpython3環境を構築したいが、標準で入っている2.x系を変えてしまうのは他にどんな影響が起きるか分からないのでイヤ。 であれば、node.jsのnvmや、rubyのrbenvなどのように、複数バージョンをインストールして切替可能な方法でインストールしたい。
pythonにはそのようなツールとして、pyenvが提供されている。
最初、virtualenvがそういうものなのかと思ったが、virtualenvは文字通り仮想環境を用意するためのもので、 パッケージなどを含めた開発環境を別々に作るためのものなので、ちょっと違うらしい。
(どちらかと言えば両方を合わせて使いたい。)
virtualenvについては別途書くことにする。
とりあえず、まずはpyenvを導入してpython3をインストールする。
このあたりを見てやってみる。
ここで紹介している手順に従うと、以下のようになる。
1. Homebrewをインストール
2. pyenvをインストール
3. pyenvでPython3をインストール
1.Homebrewをインストール
入っていないわけはないので、スキップ・・・と言いたいところだが、この手順で行う前に
$ brew install python3
とやって以下のエラーが発生していたことを思い出し、
Error: Homebrew doesn't know what compiler versions ship with your version of Xcode (8.0). Please `brew update` and if that doesn't help, file an issue with the output of `brew --config`: https://github.com/Homebrew/homebrew/issues
brew update
をしてみろというので、やってみる。
※思えばこれが道を踏み外した瞬間。
$ brew update ==> Migrating Homebrew to v0.9.9 ・ ・ ・
うまく入ったっぽい。バージョン確認もしてみる。
$ brew config HOMEBREW_VERSION: 1.0.7 (略)
2. pyenvインストール
$ brew install pyenv
無事に入ったように見えるので、pyenvコマンドを叩いてみる。
$ pyenv versions dyld: Library not loaded: /usr/local/opt/readline/lib/libreadline.6.dylib Referenced from: /usr/local/bin/bash Reason: image not found Trace/BPT trap: 5
あれ?なんだこれ。
どうも、readline 6 が見つからないと言っているようだ。
※今入っているバージョン
$ brew info readline readline: stable 7.0 (bottled) [keg-only] Library for command-line editing https://tiswww.case.edu/php/chet/readline/rltop.html Not installed From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/readline.rb ==> Caveats This formula is keg-only, which means it was not symlinked into /usr/local. OS X provides the BSD libedit library, which shadows libreadline. In order to prevent conflicts when programs look for libreadline we are defaulting this GNU Readline installation to keg-only.
そしてpyenvの問題かと思っていたのだが、実はもっと影響は大きく、bashですら起動時に同じメッセージで怒られる始末。
面倒なことになってきた・・・。
readlineの修復(readline6.3のインストール)
解決策を探して、似たケースっぽい以下を参考にした。
psqlしたらreadlineのエラーが出るようになって – はらいそ
コレに従って、readline6.3をダウンロード。( http://core.ring.gr.jp/pub/GNU/readline/ )
このダウンロードしたソースを解凍、configure、makeで インストールして brew switch readline 6.3
で切り替えしてみると、
ようやくbash でも pyenv でも起動時エラーが出なくなった。
.bash_profile に以下を追加。
#-- pyenv¬ export PATH="$HOME/.pyenv/shims:$PATH"
3.pyenvでPython3をインストール
ようやく動くようになったpyenvでpython3(この時点の最新:3.5.2)をインストールしてみる。
$ pyenv install 3.5.2 Downloading Python-3.5.2.tar.xz... -> https://www.python.org/ftp/python/3.5.2/Python-3.5.2.tar.xz Installing Python-3.5.2... BUILD FAILED (OS X 10.11.6 using python-build 20160602) Inspect or clean up the working tree at /var/folders/xw/t3s4g06x3sx4nd1xkdck0r6r0000gn/T/python-build.20161012060445.36527 Results logged to /var/folders/xw/t3s4g06x3sx4nd1xkdck0r6r0000gn/T/python-build.20161012060445.36527.log Last 10 log lines: dyld: Symbol not found: _getentropy Referenced from: /private/var/folders/xw/t3s4g06x3sx4nd1xkdck0r6r0000gn/T/python-build.20161012060445.36527/Python-3.5.2/./Programs/_freeze_importlib Expected in: /usr/lib/libSystem.B.dylib /bin/sh: line 1: 47690 Trace/BPT trap: 5 ./Programs/_freeze_importlib ./Lib/importlib/_bootstrap.py Python/importlib.h make: *** [Python/importlib.h] Error 133 make: *** Waiting for unfinished jobs.... /bin/sh: line 1: 47691 Trace/BPT trap: 5 ./Programs/_freeze_importlib ./Lib/importlib/_bootstrap_external.py Python/importlib_external.h make: *** [Python/importlib_external.h] Error 133
BUILD FAILDだと・・・
再び解決策を探して以下にたどり着く。
osx - Building Python 3 on OS X: [Python/importlib.h] Error 133 - Stack Overflow
最後のコメントに書いてある通り、 xcode-select --install
をすればこのビルドエラーは解消するはず。
こちらにも書いてあった。 しかもGUIのダイアログまで載せてあって、同じ画面を見てとても安心。
$ xcode-select --install xcode-select: note: install requested for command line developer tools
「残り約10秒」になってから10分以上待たされて、もう少しでキャンセルするところだったが、何とか完了。
再度 python3.5.2のインストールを試みる。
$ pyenv install 3.5.2 Downloading Python-3.5.2.tar.xz... -> https://www.python.org/ftp/python/3.5.2/Python-3.5.2.tar.xz Installing Python-3.5.2... Installed Python-3.5.2 to /Users/username/.pyenv/versions/3.5.2
成功!長かった。。
インストールされたことを確認。
$ pyenv versions * system (set by /Users/username/.pyenv/version) 3.5.2
最後に標準で使うバージョンをsystem → 3.5.2に切り替え。
$ pyenv global 3.5.2 $ pyenv rehash $ pyenv versions system * 3.5.2 (set by /Users/username/.pyenv/version)
これでようやく、pyenvで切替可能な状態で、python3を使えるようになった。