2015/6/9
プロダクトオーナーシップ勉強会 05
第5回。9章から11章まで。
参加している方々から、実際にこういうことをやってみたとか、そういう話が聞こえるようになってきた!!1
毎回耳が痛い感じなんですが、それ相応の成果は出てきてるんじゃないかと思えてきました。
created_at: 2015-08-06 01:43:33 +0900
updated_at: 2015-08-06 01:43:33 +0900
第5回。9章から11章まで。
参加している方々から、実際にこういうことをやってみたとか、そういう話が聞こえるようになってきた!!1
毎回耳が痛い感じなんですが、それ相応の成果は出てきてるんじゃないかと思えてきました。
ペパボの新卒研修については、昨年CTOがLL Diverで発表しましたが( GMOペパボのエンジニア新人研修 #lldiver - delirious thoughts ) 今年はさらにパワーアップして様々な取り組みを行っています。その詳細についてしかるべき時にしかるべき人が発表すると思いますので乞ご期待という感じなのですが、その中の一環として、見積りと計画づくりの話をしてほしいと言われたのでワークショップ形式でやってきました。
ざっくりと見積りや計画づくりについて説明しながら実際にやってみるという流れで打ち合わせをしていたのですが、話をしていくうちに「チームビルディングがいるな！」と思ったのが先週の金曜日。最終的な成果物や、特定の方法論に価値を見出すのではなく、大事なのは「チームづくり」「計画づくり」という活動なんだというのを強調しようと、「1つの型」という表現にしたのも先週金曜日。さらに、今朝は歯医者で虫歯の治療をして、ひょっとして始まるまでに麻酔が切れなくて変なしゃべりかたになってしまうのではないかとドキドキしながら本番を迎えたのですが、なんとかそれなりのかたちにはなったのではないでしょうか。
ちなみに、見積りと計画づくりの題材は Ruby on Rails Tutorial で、これは数年前に同じような状況で一度失敗している(とまでは言わないけど上手くできたとは言えない感じだった)ので、そのときの経験も活きたのは間違いないですね。
自分としては及第点は取れたと思っていますが、受講者からしたらそんなことなかったかもしれないので、そのあたりのフィードバックが得られてからまた詳細を整理しようかと思います。
こういう依頼が来たのも 第1回ペパボテックカンファレンスで見積りと計画づくりについて発表しました - けんちゃんくんさんのWeb日記 の発表があってのことなので、こういう方向性で押していっていいのかという葛藤はありますが、アウトプットのフィードバックが回っていていい気分です。
スパイダーモデルのNexus5にAndroid Mのプレビュー版を入れて数日経過しましたが、Twitter公式アプリがとにかくよく落ちるという点を除いて不自由なく生活できています。
前回の障害だったヤマダ電機アプリも元気に動いています。
たしかにバッテリーの持ちは良くなったかな？という印象がありますので、ローカルのデータがふっとんでもいい人は試してみるといいのではないでしょうか。
2FAの解除やバックアップコードの確認は忘れずに。(Herokuのバックアップコードを紛失してログインできない状態になっています…)
完全に書くのを忘れてたけど第4回があった模様。6章から8章まで。
GH:Eの社内勉強会リポジトリを見たらこの日からログを取るようになったみたい。
cloud-initのper-xxxについて調べたのでまとめておきます。
cloud-initは /var/lib/cloud/scripts 内にあるスクリプトを、cloud-init起動時(インスタンスの起動時)に実行します。この中には以下の3つのディレクトリがあります。
これらのディレクトリに 実行権限のついたファイルを置いておくと それぞれのタイミングで実行されます。
per-onceは、マシンイメージに対して1度だけ実行されるスクリプトを置いておきます。実行されたかどうかは /var/lib/cloud/sem の下にファイルがあるかどうかで判断されます。
ポイントは、/var/lib/cloud/scripts/per-once にファイルがあったかどうかや、新しいファイルがあるかどうかといった点は 考慮されない ということです。
cloud-init入りのベースイメージから、packerでちょっとした細工をするといったケースの場合、このpackerでマシンイメージを作成したタイミングでper-onceが実行したことになってしまうので注意が必要です。
実際の使いどころは…今の私には思いつかないので誰か教えてください…
per-instanceは、インスタンスに対して一度だけ実行されるスクリプトを置いておきます。実行されたかどうかは /var/lib/cloud/instance/sem 以下のファイルで判断されます。
/var/lib/cloud/instance というディレクトリは /var/lib/cloud/instances/#{instance-id} というディレクトリのsymlinkになっています。インスタンスからスナップショットをとってそこから新しいインスタンスを起動した場合などは、instance-idが別になるので再実行されるという仕組みになっています。
なお、EC2だとスナップショットから上手く動かないという記事をいくつか見たのですがOpenStackでは問題なく動きました。「per-onceのsemファイルを削除して再実行する」といった類のハックは必要なさそうです。
実際の用途としては、社内のOpenStack基盤だと各々云々の事情で初回のインスタンス起動時にネットワーク関連の再起動が必要になっているので、そのスクリプトを置いておく場所によさそうです。
per-bootは、インスタンスの起動の度に実行されるスクリプトを置いておきます。
監視に仕組みやクラスタに入るためのブートストラップなど、そういうのに使う感じでしょうか。
per-onceの具体的なユースケースをお待ちしています。
お手伝いしてるサービスに新しい方が来たので歓迎会でした。今週は2庄屋でフィニッシュです。
社内の有志で行っているプロダクトオーナーシップ勉強会の第3回でした。
3章から5章で資料は公開されてないっぽいのでおしまい。
藤村さんの地道なリクルーティングのおかげか、急に人がたくさん来て買い出し班は大変でした…
本編では、有識者がPOとSMになっての寸劇などもあり、みんな楽しめたんじゃないでしょうか。
寸劇の内容は、「チームがここまでできると言ったところまでできなかったことに不満を感じたPOに対してSMはどう対応すればよいか」ということがテーマだったのですが、やっとむの迫真のPOと、お酒がはいっているけど真面目に対応するSMという構図がこの会をよく表わしているなーと感じました。
会社の飲み会で1回休み。
負荷テストそのものの詳細はペパボテックカンファレンスでおいちゃんが発表した資料 EC performance testing // Speaker Deck を見てもらうとして、そのテストの裏側というか、負荷テストすると言ってもそれなりに準備しないと上手くいかないし結果を活用できないよね、という普通の話をしたくて発表してきました。
テスト計画とかシナリオの作成とか、それぞれのトピックで話したいことはあったんですが、1つに絞るとしたらやっぱり実際のデータをちょっとでも見せられて視覚的にも派手な分析と考察のところかなーと思って、そこに絞った内容にしてみました。
恐らく一定の規模のアプリケーションを運用しているところは何らかの方法で負荷テストって実施してると思うんですよ。けど、なかなか表に出てこない部分のように感じているので、少しずつオープンにしていけるといいなと思っています。
同じような悩みを持っている人、知見を共有しましょう！