イベントページ
聴講しながら取ったメモから、資料に書いてある部分を多少省いて整理したものです。まずは各発表者の資料に目を通していただくのが良いでしょう。
発表/あたりまえのことをあたりまえにやる難しさ
時雨堂 @voluntasさん
資料 http://bit.ly/atarimaenokoto
LTで発表するSoftBankの方のお手伝いなど、いくつかの企業でインフラの改善・自動化をしている。
DevOpsという言葉は使わない。自動化の話をする。
「自動化をするための準備」の話。
手動で失敗してるのに自動化しようとすると失敗する。
なので手動で成功させて自動化に持っていく。
自動化は失敗するし、コストだし、めんどくさい。
なぜ自動化したいのか？
同じことの繰り返しがめんどくさいから。
ただ、自動化したあとのことを誰も考えていない。
自動化の恩恵が得られた段階で、自動化がブラックボックスになって誰もわからなくなる。
環境を新しくする、メンテが必要になる、バージョンアップが必要になる。
メンテナンスコストで手動よりつらくなる。
コストは上がるが、効率は良くなる。
例えば、ミドルウェアのアップデートでフローが流れなくなったときそれに気付けるようになる。
「バージョンが古いことによる脆弱性や障害」から開放される。
開発者が個人的に実現する「小さな自動化」は幸せになれる。
そこには暗黙知がある。
組織全体でやるような「大きな自動化」をすると誰も幸せになれない。
レイヤー8(政治レイヤ)が問題になることも多い。
どうやれば準備段階で自動化に向けて準備できるか？
継続的に何年も続けられる、までが自動化。自動化は文化。
自分が便利になるからやる、は自動化ではない。
チームが便利になるのが自動化。
何回も何回も同じ話をして、「普通のことが普通にできる」文化をつくる。
「決まりごとの資料化」すごく大事。
自動化に関する考え方、文化を明文化しておく。
「私たちのチームはこうしていこう」という資料。
この資料がないと長く続かない、「変化を受け入れる決まりごと」が必要。
この資料、Wordはだめ。
バージョン管理して、差分を辿れるようにすること。
「自分たちに合った文化を自分たちで考える」
SIerはレビュ文化があってありがたい。
ゲーム会社はレビュ文化なかったりする。
レビュは人の成果物を見てコメントをするだけ。
「あなたが読んでわからないところを指摘しなさい」
人間、忙しくなったり疲れたりするとサボる。
偉い人や合わない人がいると対応に差が出たりもする。
レビュはモラル。
とにかく「よくわからない」にコメントしていく。
変更を加えた人はそれに対して答えられるはず。
READMEとCHANGES(CHANGELOG)を書くこと。
これによってすごくコストが減る。
必要なら「まずREADMEを読む」と明文化しておく。
差分も絶対知りたくなる、が、gitのログは見たくない。
バージョン番号の付け方、バージョニング設計をしっかりやる人はすごく少ないマイナージャンル。
これもルール化すると楽になる。
自動化の敵：優秀な人が抜ける。
なのでエースが抜けても回るようにするのが組織。
これが私の「やってきて良かったよ」。
テストの話は@t_wadaさんの記事読みましょう。
- 組織にテストを書く文化を根付かせる戦略と戦術
https://www.slideshare.net/t_wada/test-strategy-and-tactics
Q.「決まりごとの資料化」とか、どのへんをそそのかすと上手くいく？
A.やりたいかどうか、プロジェクトを成功させたい人。
偉い人からの命令なのか、現場からのボトムアップなのか。
偉い人からの命令なら生贄になってる人がいるはず。
所感
経営層・マネージャに対しては、自動化はコストであるが、継続して自動化を回せるチームを作ればサービスの品質とスピードが上がる、という投資と考えて貰うのが良さそうですね。
チームで自分たちの自動化に対するスタンスを明文化していく、というのはScrumにおけるインセプションデッキにあたりそう。ただ、プロダクトオーナーとかテックリードみたいな人だけでそれを作るのは意味がなくて、「チームで」「継続できる」ものをチームの置かれた状況を踏まえて考えていきましょう、というのが個人的にたいへん響いた点です。
LT/AWS ECSを用いたAWSへのDockerデプロイ
@legoboku さん
資料 https://www.slideshare.net/legoboku/aws-ecsdocker
イベント参加者のDocker利用率は「そんなに多くない」。
Dockerを使い始めたのはビルド環境構築。
C++製のミドルウェアで、各自で環境を作るのは大変なのでDockerで。
AMIからEC2を立ち上げるのを手動でやるのはつらかった。
開発・テスト環境で利用していたDockerをそのまま使いたい。
ECSはクラスタマネージャが設定にしたがってやってくれる。
クライアントAPIテスト環境をDockerで構築して、CodeBuildを使ってDockerイメージをビルドしていたのでECSに。
所感
時間が短かったので、途中で終わってしまったような形になったのが残念でした。DockerとECSの解説は省いて、もっと「自分たちがやったこと」「その結果どうだったか」の話が聞きたかったですね。
サービス運用でECSを使おうというときに何を考えたら良いか気になってる方は、拙著のこちらの資料もぜひご覧ください。
- これからECSをはじめる人のためのECSベストプラクティス
https://www.slideshare.net/sudoyu/jawsug-ecs-best-practice
LT/自動化におけるコード管理
SoftBank 高橋さん
資料 未公開？
GitBucketにコードが置いてあるだけ、コード管理ができていない、というマイナスのスタート地点から始まった。
コード管理に3つの柱を立てた。
- コーディング方針
- VersionUp方針
- コード管理方針
開発ルール、管理ルールを策定し、レビュ体制とProduct Managerを確立した。
ルールに則り、既存コードを修正したり、新規開発したり。
対象はPython, Shell Script, JavaScript, Google App Script, Ansible, Dockerfile, Serverspec, etc.
全部をやるのは難しいので、最初はよく使うAnsibleから手をつけた。
GitLab上で、必ず個人アカウントを使うコード管理ルールに。
- 開発者がpushしレビュ依頼
- レビュワーがレビュ
- コードが承認されたらプロダクトマネージャがmerge
レビュワーチームは新人で構成。
コーディングルールに沿ってるか沿ってないかのチェックをしていく。
開発者のルール、プロダクトマネージャのルールについては、実際できていたのは当初の想定の半分くらい。
レビュワーのルールは最初に想定した通りの内容ができた。
所感
資料の字が小さかったのがつらかったです。前から2列目でそう思ったので後ろの方の人は資料まったく読めなかったのでは。。
人数が多い新人でレビュワーチームを作ったら上手く回った、ひたすらコードを読ませて素朴に質問させることで、開発者のチームにも自然と自動化の文化が定着する足がかりになった、という印象でした。
(休憩)
LT/送信メールサービスをユニットテストしてみた
朝日ネット @zinraiさん
資料 未公開？
サーバサイドエンジニア、1年ほどかけて送信メールサービスのリプレースを1人でやった。
旧ネットワーク＋新サーバ、という中間状態を経てリプレース。
朝日ネットのフレッツ/ダイヤルアップ、朝日ネット外からのテスト、SMTP認証ありなし、入力パターンなど、かなりテストのパターンが多い。
Python3.5の標準モジュールsmtplib, poplib, unittestを使った。
動作確認が一定の品質でできるようになったほか、Undocumentedな設定を発見できた。
Firewallに弾かれたり外部への配信が失敗していたりしたら検出できない、という課題はある。
所感
ちょうど @voluntas さんの言う「小さな自動化」で幸せになったパターンですね。
たとえばこの方が送信メールサービスの担当を外れたとき、同じやり方を続けられるでしょうか？それができる人を育てられているでしょうか？というのが気になりました。
Webサービスの死活監視サービスはいろいろありますが、メール配信サービスの死活監視サービスってあるんですかね？
LT/DevOpsとドキュメントデザインパターン
リクルートテクノロジーズ @yuzutas0 さん
資料 https://speakerdeck.com/yuzutas0/20170703
「インフラ」「運用」「開発Tips」の3つのディレクトリにそれぞれ手順書があって、同じ手順書を参照すべきなのに別のデグった状態の手順書を参照することで問題が起きたりしていた。
局所最適化の悪循環を止めるため、ドキュメントから攻めた。
まるでレガシーコードのような有様だが、直し方もレガシーコードと同じと考えMVCっぽく整理した。
所感
少なく見ても15分はかかるであろう濃密な内容を3倍速でお話いただいたので、早口すぎて脳みそがついてきませんでした。早口名人とかアナウンサーになれそう。あの活舌の良さはすごい。
資料を見る限り、Appendixの内容も含めて20～30分くらいのセッションで、ゆっくり聞いてみたいなーと思わせる内容ですね。
発表/DevOps、本当のところ
ファーストリテイリング @shot6さん
資料 未公開？
コアエンジニアリング部というところにいて、内製化を中心とした開発チャレンジをしている。
開発というよりはマネージャ、チームビルディングを中心にやっている。
関谷さんにはめられて登壇。
ユーザ企業としてこう悩んでます、という話をする。
コアエンジニアリング部は技術選定・構築など、日本発のグローバルエンジニアリングチームで事業貢献。
大きく4つのグループに分かれる体制。
- Application group (UI/UX, EC Web App)
- Platform group (Platform Engineering, Data Engineering)
- Architecture group (Architecture, DevOps)
- Infrastructure group (SRE, Network, Communications)
いろんな人を説得しないといけない。
SIerがからむと内製に難しさがあるが、企業規模上避けて通れない。
パートナーは、契約をどうするかとか、人が抜けるとかいった課題がある。
オンプレやめてすべてクラウドにする。
AWS:8リージョン4000台
Azure:150台
利用しているソフトウェアスタックは stackshare.io で公開している。
幅広くやっているので個別にそれぞれの事情があり、GoのところもあればPHPのところもあるといったような状況。
そもそもDevOpsとは、というのをWikipediaで見てもちょっと香ばしい。
抽象的な概念で、人によって受け取り方が違うので、文化を語ると失敗すると考えている。
ファーストリテイリングでのDevOps、インフラの自動化、デプロイの自動化はかなりできている。
Dockerベース、ECS/ECRとJenkins、リリースノート(CHANGES)の生成、Slackへの通知など。
Microserviceがコンテナで動いてるので、Google(GCP)に置き換えても同じ構成がとれる。
みんなドキュメント書いたり、ドキュメントに従ったりするのが苦手な人が多い。
標準化、大きな粒度での自動化に悩みを抱えている。
エンジニアだけ、ツールだけで効果が出るのは限定的。
大きな失敗を繰り返してきた。
いちど、高い理想の状態に向かっていこうとしたがまったく機能しなかった。
現場からの信頼感が得られず、現実にそぐわなかった部分が埋めきれなかった。
時間とコストを費やしたが、5現(原理・原則・現場・現実・現物)に反していた。
文化を変える1歩目が動かない。
結果として文化は変わるもの。文化を変えるものではない。
今のアプローチは、理想より具体性のある変化・実施を優先。
対話と相互理解で、まわりのチームがメリットを感じるようにあとから描く。
小さな1歩が動きやすいようにする。
チームのプロセスに踏み込んだりしないといけないのでめんどくさかったりするが、それが技術負債と向き合うということ。
どういうところに課題を感じているか？を見える形で整理した。
課題・目標・短/中/長期・効果
最初の1歩、2歩から肌感でわかるように。
- 自動化のために返済しなくてはいけない大量の技術負債
- 人不足、仕事の分量の見直し、プロセスの見直し
- 全員がコンフォートゾーンから出る必要性
といった学びがあった。
ツール選びで何かが変わるわけではない。
運用負荷を劇的に下げたい、属人化を防ぎたい、グローバル展開を楽にしたい、そういった思いのもとに問題解決と向き合えるかどうか。
DevOpsの実現には本質的な組織文化の転換が必要。
もともとが内製中心の発想なので、契約面の工夫や、評価制度そのもの。
DevOpsやってる人が評価されるように。
システム開発の話ではなく、ビジネスのバリューストリーム全体で見ること。
システム開発がボトルネックであることはほとんどない。
自動化がやりやすい要求になっているか？で勝負が決まることもある。
ツールへのこだわりを捨て、ボトルネックの解消目線で取り組む。
考え方を理解している人がやってるか、そうでないか。
プロジェクトマネージャ、ピープルマネージャが価値を見出しているか。
DevOpsエンジニアにリワードがあること＝人事に理解して貰う。
フィードバックループを正しく回す努力をどう評価するか？
人材定着やスタッフィングに理解がなければ破綻する。
DevOpsツールから組織文化の変革には結びつかない。
DevOpsという言葉は忘れよう。
ビジネスとしての費用対効果を考えよう：事業貢献、ボトルネック解消。
過程に価値があり、結果としての自動化だけを見ていると本質を見失う。
評価制度がないと長期的には定着しない、技術負債だけが残る。
世のDevOpsマーケティングはそういった観点で価値を見定めよう。
We are hiring 、これまで話したような前提に立って、ITのポジションを広く募集している。
UI/UXからクラウド、Microserviceやデータアナリストなど。
カジュアルなMeetupもやっているのでご興味があればぜひ。
Q.開発と運用の橋渡しをやっているが、なじまない人にはなじまない。
評価されれば馴染むだろうと考えているが、どうやって根付かせた？
A.開発の受益者を巻き込む、部長とかそういうクラスの人。
人材の必要性を明確に示す。1年ちょっとかかった。
所感
エンジニアより、むしろ経営層・管理職や人事担当者にこそ聞いて欲しい内容でした。世の管理職の、いったいどれだけの人が「自動化する文化の定着」と「それに対する評価」に労力を割いているでしょうか？
エンジニアにとっては、エンジニアとして個人的に役に立つ、というより、「最高のエンジニアリングチームを作りたい」ときに役に立ちそうです。そんなときのために人事部門と仲良くなっておくと、DevOps文化を評価する基盤づくりが楽かもしれませんね！
※ただしユーザ企業に限る。という感じです、内製じゃない開発をしている？残念！
おわりに
文字の小さいスライドが多かった印象があります。おそらく、(10人以内くらいの)社内会議で使った資料の使い回しなどもあるのでしょう、生々しい感じの資料があって、そういったものを見ることができたのが良かったところでもあります。でもやっぱりもう少し字が大きいと見やすいです。
長～いレポートになって正直すみません。メモの量が多くて、短くまとめるのは諦めました。
もし一通り目を通した、という奇特な方がいらっしゃいましたら、ぜひ思ったことを一言二言でもコメントください。
会場・懇親会のスポンサーのSoftBankさま、発表者のみなさま、ありがとうございました。