Scrum Boot Camp Premium

久しぶりの有料講習に参加してきました。

アジャイルアカデミー・Scrum Boot Camp Premium
http://event.shoeisha.jp/aa#Lesson4

もちろん参加するずっと前にこの本を読んでいたのですが、やはり本だけじゃホント全然ですね。
この手のプラクティスは、ワークショップに参加して実際に身体でやってみるのが一番です。本当にいろいろなことを肌で実感できた一日でした。

自分の場合は、アジャイルもスクラムもほとんど実際の現場では使っておらず、もっぱら本だけの知識だけで望みました。

全体を通して行ったことは、スクラムの基礎について説明を受けながらグループで簡単なモデル作業のスプリントを1つ実施し、その後、細かいプラクティスについて1つずつ課題を与えられつつグループ全員で検討したり作業したり答えたりしていくことで、身体でスクラムを学んでいくような流れです。ブートキャンプということで、説明を聞いたかと思うとすぐにクイズや課題が矢継ぎ早に飛んできて、結構脳に汗をかくような構成でした。

プロダクトオーナーを探したり、プロダクトバックログを全員で出し、そこから見積もりをしたり、スプリントの計画を立てたり、スプリントバックログを出したり、実際のモデル作業をしてその振り返り(レトロスペクティブ)を行ったり・・などなど、グループを組んだ見ず知らずの方々と一致協力をして実際に手や体を動かしてプラクティスをこなすことで、スクラムをエッセンスを知ったり、普段の身の回りの問題点や課題がスクラムのフィルターを通して棚卸されたり、また他の方々の普段の仕事や課題のお話を聞いて、自分の身の回りに照らしあわせて議論していったりすることができました。

趣味で登山を始めた時に思い知ったのですが、たとえ、どんなに本で読んだりして、自分の中での理屈や理解としては説明不要で明らかであったとしても、実際にやってみて初めて分かることは本当にあります。特にスクラムのような「生身の人間」相手のプラクティスの場合は尚更で、改めて、人間のコミュニケーションには様々な確認や理解の支援などのようなサポートがいかに必要であるかを実感しました。

また、とっても面白かったのは、全然知らない人同士でグループを作ったにもかかわらず、いざスクラムのプラクティスで作業を行ったりした途端に、自分が普段の見ている開発の仕事では見たことがない、「全員が積極的にリーダーシップを取って課題に関わる」というチームが出来上がったことでした。

ウォーターフォール云々という以前に、自分は普段の仕事において「指示を出す側」と「指示を受ける側」というロールにいかに自らハマっているかということを思い知ったような気がします。出す側は、無意識のうちにいつも出す側としてのスタンスで行動し、受ける側はいつも無意識のうちに作業指示を受ける体制を取ってしまう。スクラムの基本である「全員で見積もる」とか「全員でスプリントバックログを出す」とか「全員で振り返る」、「全員で改善点を話し合う」などを通じて、こんなにも普段の「無意識ロール」から離れて、立場を超えて全員で「よりよいプロダクトを作ろうとするロール」を身にまとえるのだな、ということを感じました。

きっと、本当はみんなそれぞれ根底にはそういう前向きな意識をいつも持っていて、その出番を待ち続けているのかもしれませんね。

私の仕事の立ち位置としては、なかなかスクラムのようなプラクティスを現場に導入するのは難しいですが、少しずついろんな作業分野で適用していって、チームをより創造性のある方向へ持っていければと思います。

AWS GameDay !!!

gameday

Publickeyさんのこの記事→「「Obama For America」の開発チームが作り上げた大規模な選挙キャンペーンシステムの舞台裏(後編)」で非常に気になっていた「GameDay」が、なんと日本で開催されるとのことで参加してきました!
上の写真は、この素晴らしいイベントを開いて下さったObama for AmericaチームのボランティアメンバーのMiles Wardさんと、AWSソリューションアーキテクトチームの皆さんです。ありがとうございました!

普段全然AWS使ってないし・・そもそもアプリ屋の人だし・・スゴそうなメンバーがいっぱい集まりそうだし・・って思ったのですが、イベント概要に「システムに関わる全ての皆様の参加をお待ちいたします」ってあったし!「チームで対戦形式としますので、ノービスからシニアまでご遠慮なくご参加ください」って書いてあるし!それ以上にとにかくやってみたかったし!ってことで飛び込んでみました。

終わってみたら、本当にとてつもなく楽しいイベントで、帰ってきてもなかなか興奮がさめないでいます。
取り急ぎ、もろもろを書いておきます。以下長いです。

イベント概要 「AWS Game Day Tokyo 2013」 日本初!対戦型システム信頼性向上策を体感しよう!
公式サイト AWS GameDay
開催報告・ルール概要など
AWS Game Day Tokyo 2013 開催報告 – Part 1 : Unclouded Eyes
AWS Game Day Tokyo 2013 開催報告 – Part 2 : Unclouded Eyes
AWS Game Day Tokyo 2013 Vol.1 – flickr

自分のAWSスペック

  • 仕事では使っていない。
  • 3時間くらいのハンズオンを受講して、S3で静的なHTMLのサイト作成とか、EC2の作成から簡単なVPCの構築までを体験。
  • それ以外は個人のアカウントでEC2を作成、gitなどをインストールして開発環境を構築したり、簡単なコマンドを叩いたりした程度。
  • 普段の仕事はアプリ屋でインフラ構築は携わっていない(開発環境を作る程度)

参加前にやったこと

さすがにAWSに慣れてなさすぎて、攻撃・防御に四苦八苦したくなかったので、いろいろと予習してみました。これが結果的に自分のAWSの基本スキルを上げることになって一石二鳥w。やっぱり何か目的があると勉強しやすいですよね。あと、クラウドデザインパターン本が面白くて役に立ちましたです。

Amazon Web Services クラウドデザインパターン設計ガイド
Amazon Web Services クラウドデザインパターン実装ガイド

  • クラウドデザインパターン本を薄い方と厚い方を両方読む
  • 自前のアカウントで以下のことを自習としてやってみた。
    • RDSにMySQLのインスタンスを作成
    • EC2を作成してApache、PHP、Wordpressなどをインストール。DBはRDSに作ったMySQLを使う
    • 作ったEC2をAMIに保存
    • AMIから複数のEC2を作成・CloudInitにも初期化スクリプトを設定(これはスクリプトを調整しながら何度か繰り返し)
    • ELBを作成し、複数のEC2にロードバランスする構成を作成
    • 攻撃用にjmeterのスクリプトテンプレートをいくつか作成(DDosとか、データあふれさせたりするのとかに使えないかと思って。結果として未使用でした)

システム概要

用意されたシステムは簡単なバッチのクラスタ構成でした。それを準備段階で手順書を見ながら構築します。処理の流れとしては以下のような感じです。

  1. 複数の画像のURLをSQSのキューに流す
  2. サーバーに常駐したスクリプトがキューを取得、画像をダウンロードしてローカルに保存しImageMagickで合成、その画像をS3に保存する
  3. 処理結果と保存先URLを出力用のSQSにキューとして登録

これらの構成に対して、AutoScalingと監視用のCloudWatchを設定し、負荷に応じて自動的にスケールするバッチクラスタを構成します。

ずっとWebシステムをイメージして準備していたので、問題が明らかになったときにまさかのバッチクラスタwって思いました。でもそんな意表をつかれたのも面白かったです。

ルール概要

以下を参照。
http://www.slideshare.net/kentamagawa/aws-gameday-tokyo2013-22642423

PowerUser権限を持つIAMユーザーを作成し、それを交換して相手チームのAWS Manegement Consoleにアクセスして攻撃します。なので、簡単な全消しとかはもちろんナシ。相手に気づかれない方法でシステムを壊すことが高評価につながります。また、PowerUser権限では相手チームのサーバーにはログインできません。

ルール概要にある「攻撃によりコストが発生してはいけません」とは、要するに「課金増やす攻撃はなし」ってことですw。

チーム

基本は3人チームでしたが、自分のチームは人数の関係で2人体制でした。チームメイトの@Canelmoさんはお仕事でもAWSを使っており、AWSのコマンドも手慣れていて手がとても早い方でした。なので、AWSのコマンド系は彼が主に担当し、ブラウザから実行できる設定などは自分がやるなどの分担をしました。チーム名は2人の趣味とか好きなものとかをいろいろ出し合って、チームFujinomiyaに決定!

システム構築および防御

手順通りに構築して行ったのですが、最後あたりでまさかのリージョン違い問題が発生(東京リージョンで構築したのですが、バッチスクリプトはデフォルトのUS Eastで動くようになってた)。スクリプトを修正しようかとも思いましたが、時間がなかったので、運営の方からチート用wのCloudFormationの構成をもらって、ポチッとなって感じで全構成を自動作成しました。ここでこのCloudFormationの凄まじさをまざまざと実感する結果にw


まさに負け組かとw

「CloudFormationで作っちゃったからシステムにイマイチ愛着わかなかったです」とはチームメイトの談wやっぱそうですよね。その上、防御用の独自設定は時間の関係でほとんどできなかったです。

次こそは!

攻撃

以下の攻撃を実施しました。
攻撃時間が20分間なので、短い時間の間にアイディアを出して、すぐにそれを実行してみる緊張感が楽しかったです。

  • バッチスクリプトを読んだところ、画像をダウンロードするwgetコマンドにコマンドインジェクションの脆弱性を発見。それを利用することにした。(ちなみに、それを防ぐパッチをあてたチームが見事ベストディフェンス賞をゲットしました。おめでとうございます!)
    • 攻撃されるアカウントとは別のアカウントの方にEC2のWebサーバーを建てて無限リダイレクトが発生する画像URLを設置。それを使って「—max-redirect 99999999 http://無限リダイレクトのURL」をキューに流した。
    • 入力キューのURLに、「chmod 000 /バッチの出力ディレクトリ」をコマンドインジェクションした(成功したかは未確認)。
  • SQSのキューの「Delivery Delay」を最大値の15分に設定した。
  • S3のバケットポリシーに書き込み拒否を設定。
  • オートスケールの設定を、最大・最小共に1に設定。
  • オートスケールの設定に、1分おきにインスタンスが停止するように設定。

受けた攻撃

SQSのキューとS3バケットの名称をほんのわずかに修正された。「o -> O」のような感じでw。
その結果、キューにアクセスできなくなったため、バッチプロセスが終了してしまっていた。

修復

CloudInitに設定してるバッチの起動スクリプトに書いているキュー名とかバケット名を修正。しかし、これがなぜかなかなか面倒でした。しかも完全に正しく修正しているのにも関わらず、なぜか何度EC2を起動し直してもバッチが正常に起動しなくなる現象が発生。だいぶ調べましたが、どうにも原因がつかめなかったので、最後に時間切れでCloudFormationをポチって、システム再構築しましたw。修復としてそれアリなのかという議論はもちろんありますが、今回はDBなどがないシンプルなシステムだったので、(本当は自分たちでCloudFormationを構築していればw)アリなのかと思います。

それにしても、名称の変更って地味に分かりにくいし、地味に効果的で、地味に修復にも手間取るので、単純ながら以外にやっかいな攻撃だと思いました。

そんな風に修復に手間取っていたため、修復後に流せたのはわずか1件のキューのみ。しかし、それがまさかのFunniest Image賞に選ばれましたww

ホントは3枚くらいまとめて流したかったビンタ画像w 「攻撃する人なんてこうよ!」って意味にしたかったので。
20130609143831

感想など

とにかく本当に楽しかったです。
短い時間の中でアイディアを出しあってそれをすぐにオペレーションしたり、ソースコードを読んでコマンドインジェクションの脆弱性を見つけ出したり、同じ部屋の別チームと攻撃方法を共有しあったり(ファイルを入れたUSBをまわし合ったり)、その日初めて顔を合わせた方と2人で、サーバーがうまく動かない事象を喧々諤々Shellを叩いて調査し合ったり、遊びながらどんどん創造性が湧き出てくるようなひとときでした。

予習は比較的役に立ちました。特に2人チームだったので、自分が全部教わりながらだと間違いなくもっと時間が足りなかったはず・・。終わってみれば、基本的なAWSの機能群に加えて、CloudFormation、AutoScalingなどの機能とその威力などが理解できて、非常に有意義な勉強になりました。

他のチームの創意工夫に富んだ攻撃方法や防御方法も興味深い物が多く、得られた物が本当に多かったです。遊びはスキルを一気に延ばす力があるということも改めて実感しました。

終わってみて

  • CloudFormationの復旧最強かも。CloudFormerも調べてみたい。
  • 自分がいつも使う各種スクリプトのテンプレートや設定ファイルなどは、githubのようなところに上げておけば、EC2サーバーにすぐに反映しやすくていいかも。
  • Mac同士ならAirDrop使うと鍵ファイルとかの転送が手早く簡単で良いです。Windowsの場合は共有作ったりするしかない感じ?あらかじめなんかアプリを入れておくといいかも。
  • ブラウザで別々のアカウントでAWSにログインしたい時は、Chromeの場合では片方のアカウントをシークレットモードでアクセスすると同時に使えるので良いです。
  • スゴく時間がなかったので、弁当持参だったのが昼の時間も使えてよかったです。
  • コマンドインジェクションなんでもできるので怖い!!でも、この手はさすがに次は使えないかも。。自分も次は間違いなく先に見つけてつぶすと思うし。
  • 次は絶対にキチンと防御まで構築して、攻撃側をだます罠とか、自動修復までするようなシステムを作っておきたい!

そして、チームメイトの@Canelmoさん、2人チームでしたがホントに楽しかったです。ありがとうございました!

次も絶対参加したいです!

リテラリーマシン ハイパーテキスト原論

“ 世界が変わるたびに、価値観が変わる。
 私たちが世界の相当な部分を定義し直すたびに価値観の変化が起きる。それはずっと繰り返されてきたことだ。発見と呼べない発見や、目新しいだけの世界観の発明を通して。
 とはいえ、それにもかかわらず、私たちは今日現在の世界観こそが正しいのだと信じている。なぜなら同じことの繰り返しのなかから、一度にひとつの視点からしかものを見ることができないと悟ってしまったからだ。”
(リテラリーマシン―ハイパーテキスト原論 7ページより引用)

写真 2013-05-10 23 51 20

enhcantMOONを勢いにまかせて予約してから、なぜかふとこの本のことを思い出して読んでみた。もはや本屋では手に入らず、ネットでも古本屋で倍以上の値段でしか手に入らないとは、時代は過ぎたものである。地元の図書館に行って、しかも自動書庫からの出庫をお願いしてなんとか借りることができた。

テッド・ネルソンのことも、ザナドゥのことも、知ったのはたしかWindows3.1の頃。当時からその人物像もプロジェクト像も極めて伝説的なイメージで、偉人伝のようにしか認識していなかったのだが、まだインターネットにすら触れられることがなかった当時は、この本を読んでもその目指しているものやその理屈なんかはほとんど理解できなかったのではないかと思う。そう実感するほどに、今この2013年に読むと本当に「しっくり」来るのである。各種の評判もさることながら、あとがきにまで「奇書」と書かれているような本なのだが、「ハイパーテキスト」「ハイパーメディア」を提唱したのが1965年、そしてこの本の原著が自費出版(!)されたのが1980年なのだから、とにかく新しすぎて、また途方もない夢のような世界であり過ぎた故に「奇書」「奇人」と評されたのではなかろうかと思う。

なぜなら、今この年に読んでも、まだまだ時代はこの本に追い付いていないのだから。

どんなに「奇」なる本と評されようとも、自分は、まさに「理想郷」と呼ぶべき文書空間がこの本では提唱されていると感じた。

全て文書が電子化され、バージョン管理可能な普遍的な電子出版システム。
相互参照可能で、さまざまな意味づけができ、文書のバージョンにも紐づいたハイパーリンク。
課金システムにも組み込まれ、ハイパーリンクを拡張した「引用」であるトランスクルージョン。
今でいうところの「クラウド」を彷彿とさせる分散文書管理システム。

ザナドゥ自体は現時点では確かに実現には程遠い状態であり、「コンピュータ史上もっとも長く続いているベーパーウェア」のように揶揄されていたりもするが、現代のWebや電子出版とその販売システム、文書を参照するためのタブレットやハードウェア、クラウド化された文書管理など、時代はとても遅い足取りながら、しかし確実に「ザナドゥ」に吸い寄せられているように思う。

本そのものは手に入らなくなっても、時代はその提唱した世界に確実に近付いているというのは、この「原論」がいかにとてつもない「原石」であるかの表れであるように感じてならない。

じっさい、仕事でさまざまな設計書やドキュメントをExcelなんかで書かされる毎日を送っていると、ザナドゥの世界はため息交じりに見る夢のまた夢のように思えてならないが、しかしそれでも、実現不可能な世界ではないし、コンピュータにおける文書はこの本で示されているように作成および管理されるべきであると思う。文書はバージョンで管理されるのが当然だし、ハイパーリンクはバージョンに紐づくべきだし、引用は、どんな部分でも自由に範囲指定し、それもバージョンに紐づいているべきである。また現在もリリースが継続されているアプリケーションであるMediaWikiは、限りなくその世界に近い機能が実装されており、それをベースに作られたWikipediaは、世界で最も成功しているハイパーテキストシステムであることは疑いの余地はない。

本当に全く手が届かない世界ではないし、見果てぬ夢でもないし、いずれは人類が到達できる世界が書かれていると思う。

そして、雑然とした文書ファイル群を目の前にする日々を送っている中でも、この本が目指すところを忘れることなく、日々自分のコンピューティング空間をよりよくする努力を怠ってはならないことを再認識した一冊だった。