Zabbix 2.2アップデート
Zabbix 2.2アップデート
利用者へのメリット
パフォーマンスが改善されている
キャッシュの拡張、データベースアクセスの最適化、および処理アルゴリズムの改善等大小様々な改良によって 2.0に比べて 2～5倍 全体的にパフォーマンスが向上している。
グラフ処理性能や監視設定の変更操作のWebインターフェース、ログファイルの監視といった監視自体の性能も向上している。無効ホストの過去データ参照
監視を無効にしている環境の過去データが参照可能となった。
これまでは対象環境の電源がオフの場合、監視を無効にする必要があったためリソースを後で確認することができなかったが
対象環境を停止している状態でも、性能負荷試験実施などの過去リソースを見ることができるようになる。Web監視の改善
Webコンテンツの再利用（前リクエストのレスポンスの一部を後続ステップで再利用）ができる。
また、リトライ回数の指定やweb監視時に個別のＨＴＴＰプロキシの指定ができるようになる。
運用者へのメリット
VMware監視
VMwareハイパーバイザーとVMのリソース監視ができるようになる。
これまでもZabbixエージェントを入れることで監視可能であったが、
仮想環境特有の監視内容などをハイパーバイザーから取得するようになった
（現時点で利用の必要性はないかもしれない）バージョンアップが容易
データべースの自動アップグレードがサポートされており、アップグレード時の時間も短縮されている。Zabbixプロキシの自己監視
Zabbixプロキシの内部チェックがサポートされ、動作状況やリソース使用状況を見ることができるようになる。イベント関連の改善
不明トリガー、取得不可アイテムの障害通知がおこなえるようになる。
監視が正しく行えなかったとき（監視対象のログが消失した等）に障害通知を行うことが可能となる。-
- セキュリティ問題の修正
- 認証・権限の問題
- SQLインジェクションの問題
- メモリーリーク問題の修正
- クラッシュする問題の修正
- キュー計算時にZabbixServerがクラッシュする可能性がある[ZBX-8060]
- Zabbixサーバーから正しくないレスポンスを受信した場合にZabbix senderがクラッシュする[ZBX-5741]
- 監視問題の修正
- サーバ起動中・ネットワーク問題・によるZabbixProxy からのデータ消失の修正[ZBX-6526/ZBX-6249]
- Zabbix senderでファイルからデータを送信した場合の問題を修正[ZBX-5732]
- proxy からのデータ取得が不正な場合がある[ZBX-7133]
- ログサイズと更新日が保存されない問題の修正[ZBX-6929]
- ログ出力の改善
- エージェントがサーバー/プロキシへの接続に失敗した場合にワーニングログを出力するように修正[ZBXNEXT-1056]
- WebGUI改善
- IEでの操作時の非表示問題改善(ホストグループ)
- セキュリティ問題の修正
【参考URL】
公式ドキュメント
https://www.zabbix.com/documentation/2.2/manual/introduction
http://www.zabbix.com/jp/rn2.0.4.php
http://www.zabbix.com/jp/rn2.0.5.php
http://www.zabbix.com/jp/rn2.0.6.php
http://www.zabbix.com/jp/rn2.0.7.php
http://www.zabbix.com/jp/rn2.0.8.php
http://www.zabbix.com/jp/rn2.0.9.php
http://www.zabbix.com/jp/rn2.0.10.php
http://www.zabbix.com/jp/rn2.0.11.php
http://www.zabbix.com/jp/rn2.0.12.php
http://www.zabbix.com/jp/rn2.2.0.php
http://www.zabbix.com/jp/rn2.2.1.php
http://www.zabbix.com/jp/rn2.2.2.php
http://www.zabbix.com/jp/rn2.2.3.php
http://www.zabbix.com/jp/rn2.2.4.php
http://www.zabbix.com/jp/rn2.2.5.php
Zabbix 2.2の新機能とZabbixオフィシャルサービスの紹介
http://www.slideshare.net/KodaiTerashima/20130802-osc2013-kyoto
「Zabbix 2.2は最も優れ、安定したリリース」、開発者が語る
http://www.atmarkit.co.jp/ait/articles/1311/22/news150.html
--
気になったバグフィックスりすと
- セキュリティ問題の修正
- [ZBX-7703] fixed being able to switch users without proper credentials when using HTTP authentication
- [ZBX-7693] fixed admin user being able to update media for other users; reference CVE-2014-1685
- [ZBX-7091] fixed SQL injection vulnerabilities in page filtering
- [ZBX-7091] fixed SQL inection vulnerabilities dashboard favourite managing fixed trying to change the status of a deleted trigger or trigger prototype changes the status of all trigger and prototypes
- メモリーリーク問題の修正
- ZabbixServer/ZabbixAgentがクラッシュする問題の修正
- [ZBX-8336] fixed server crash with value cache is working in low memory mode
- [ZBX-7836] fixed possible crash when a value older than the last item value was added to the value cache
- [ZBX-8060] fixed server crash when calculating queue
- [ZBX-5741] Zabbixサーバーから正しくないレスポンスを受信した場合にZabbix senderがクラッシュする問題を修正
- ログ出力の改善
- [ZBXNEXT-1056] アクティブエージェントがサーバー/プロキシへの接続に失敗した場合にワーニングログを出力するように修正
- 監視問題修正
- [ZBX-5732] Zabbix senderでファイルからデータを送信した場合の問題を修正
- [ZBX-6526] fixed possible data uploading issues duing server startup or network problems proxy からのデータ消失の修正
- [ZBX-7133] fixed processing of zabbix[host,*,available] item; fixed proxy's hosts availability data on server proxy からのデータ取得が不正な場合がある
- [ZBX-6929] fixed updating of lastlogsize and mtime in the proxy's database
- [ZBX-6249] fixed data loss in proxy "Data sender" process caused by unfinished transactions[ZBX-6129]
- [ZBX-6835] fixed bug when agent/proxy connection error could have resulted in a wrong warning about message size
- [ZBXNEXT-166] fixed proxy not storing items with text value type
- [ZBX-7968] fixed bug when proxy stopped sending history data if it had more than 1000 unmonitored item values in history table
- [ZBX-8202] fixed queue calculation for unavailable hosts which are monitored through a proxy
- IEでの操作時の非表示問題改善(ホストグループ)
第5回elasticsearch勉強会にいってきました
静岡からの参戦。 しかし遠いなぁ、定時即でぎりぎり。 もう少し近ければいいのに。 例のごとく道に迷いながら時間ギリギリでたどり着きました。
Elasticsearchトレーニングに参加している先輩２人と合流してお勉強会スタート。
@yusukeさん、同時翻訳ありがとうございました！！
もう英語力がなさすぎてちんぷんかんぷん。 基本的に同時翻訳をごりごりメモらせていただきました。 ちゃんとまとめきれていない、個人めも程度です。ごめんちゃい。
タイムテーブル１
Honza Kral / @honzakral さん Elasticsearchのpythonクライアント作っている人とのこと。 なかなか渋い色のElasticsearchTシャツを着ていた。
1.0の新機能であるaggreagationについて。
このスライド、後で読む
- aggreagationはネストできるfacetらしい。
- aggreagationの中にさらにaggreagationを記述できる。
- デモでは１つのクエリでドキュメントのヒット数、トップコメント、コメンタのスコアなどを取得できた。
- キーのstringがとれるようになった(?)
あとpythonクライアントの話。 クエリとかフィルターがメソッドチェーンで簡単にかけるらすぃ。けどpython使ってなかったのでふむふむ、とした感じ。 んー、でも簡単なツールならこっち使った方が簡単かも。
aggreagationは結構目玉機能な感じ。 必要なときに必要なものしか調べない（悪い癖）からこういうのについていけていない。。。 ちょっとさわってみて、今度まとめてみたいと思う。
タイムテーブル2
Igor Motov / @imotov さん Elasticsearchの開発者。snapshotとか作っているらしい。 基本的なところからluceneや内部の動きについて。
※追記 資料が上がっております。
- file descriptors 32k -> 64k この辺りの設定とか重要
- 言葉の意識合わせ
- master node
- cluster state
クラスタ構成中のみ存在する情報（永続化されていないという意味？？いや永続化されている？？？） - data
- データはproximity(近さ)によっていろんなレベルで保管される
- elasticsearch.ymlや--path.data on command lineでデータディレクトリを指定できる
- １つのdataディレクトリを複数のノードで共有することも可能
data_dir内のサブディレクトリにノード別に保管しているので (data/elasticsearch/nodes/0 みたいな感じで確かにべつものになる。) - state
デフォルトでesはjsonフォーマットで保管している
ymlファイル見るとformatとしてのjsonが指定されている（なんと、気づいてなかった） →んー、ローカルのやつはとてもjsonではない。設定もどこで指定するか見当たらない。。。 - node.lockというファイルがあり、競合がおこらないようになっている
- クラスタの_stateというディレクトリにはメタデータが保管されている
（cluster setting apiのやつとかだっけ？） - インデックス内のstateにはaliases mapping setting など インデックスのメタデータ
0 / 1 / 2 インデックスがシャードとして保管されている。
ここにもstate(メタデータ) これはシャードメタデータ
- transaction log
lucene segments
- every 30min 200mb or 500 operation
lucene indexについて
stored fields
- デフォルトで格納している
内部の動き
- クラスタの状態を確認しシャードがどのノードにあるか確認する
- シャード１つないで何が行われているか
シャード内では各セグメントをなめていきます。１つずつ。
１つのセグメント内では転置インデックスを確認してdistributedはdoc1にあることがわかる。
つづいて日付でソート field dataより - top 10 document correct for each shard -> grobal top 10 doucment
masterがマージしている。 - シャード内ではノードで指定したドキュメントが格納されているセグメントから
ドキュメントのテキストをひっぱってきてノードがシャードからかえってくる情報をマージしてレスポンスを返す。
QA time
フェーズを２つに分けてる理由は？
ドキュメントIDを割り出し（クエリフェーズ？）、フェーズ２で詳細情報を取得すると(fetchフェーズ？)
stored filedの情報が必要ない場合、フェーズ２はいらないんじゃないか？
シャードが返すidはドキュメントのidではなくてセグメントのidと位置。 クエリフェーズで実行した場合luceneのidをかえす （内部的にはluceneの転置インデックスから内部のidをかえす） パフォーマンスが早いのでこのタイミングでフィールドは見に行かない 先にトップ１０ドキュメントを洗い出してよりコストの高い処理をフェーズ２で行う ユーザが指定したdoc id を全シャードで調べて返すと重いよ countだけつかうならばsearch-typeでフェーズ２をスキップできるよ
transaction log
検索パフォーマンスには影響しない（transaction log） fsyncはディスクに書き込まれていることを確認/ensureする作業 そしてfsyncされた情報からセグメントを生成する esのrefreshを行うと発生する→transaction log の書き込み つまりtransaction logを生成したタイミングでは検索できない
apacheのアクセスログ解析に使っている人、多分Elasticsearchに入れたらログ消してもいいかな？的な？
jsonドキュメントをesに渡したらデフォルトではjsonまるまるesに格納されている esにすべての情報が格納されているという前提でよいか
多くのユーザーはデータリソースを別に持っていて簡単に再ビルドできるようにしている プライマリにはまだ使わないでほしい。別のとこにデータのこしておいて。
なぜクラスタstateの情報をnodeのレベルで持っているの？
クラスタは論理的なあつまりで、ノードの集合に名前が付けられたもの クラスタはつまりノードが動いている間しか存在しない クラスタが消えた場合ノードでも動けるように個別に持っている
Shay Banon登場
なんでFDを設定する必要がある？
luceneインデックスは複数のセグメントで構成されている どんどんたくさんのインデックスを作っていくと、セグメントができまくって１つ１つのセグメントを検索する必要が出てくる たくさんセグメントができるとあるタイミングでマージする必要がでてくる 効率的に検索するための最適なセグメント数がある
インデックスは複数のシャードで構成されていて、シャードは複数のセグメントで構成されていて セグメントは複数のファイルで構成されている。ので。FDの設定が大事。 内部通信用にも使ったりするしね。
kibana
aggreagtionはkibanaのため。facetでは十分な情報がとれなかった kibana4が作られている。そっちをお楽しみに。 １つのhistogramに異なるフィールドを出すこともできるようになる！！！ これは期待！！
なんでesをつくったか
すげー暇だったからw icookという奥さんのためのレシピ検索を作りはじめたのがきっかけ。 検索ボックスが１つあって何でもそこから検索できるような。 そこからいろいろなものを使ってみたけどイマイチしっくりこない感じでー。
スナップショット機能を使っていて、現状２０００スナップショットあるんだけど性能でない！
POSTがめちゃくちゃ遅い。数が大杉？
スナップショットはインクリメンタル。 過去分をみて保存できていないものを保存する仕組みなので、過去のスナップショット数が多くなると遅くなる。
定期的にあたらしくつくったほうがいいのか？
想定していない使い方かもしれないけど、それが必要があってやっているなら教えてください。なおしますよ。
relevanceあたりのドキュメントがちょっとわかりにくいかも？
まず、ドキュメンテーションは現在頑張ってます。 無料のebookがあるので読んでみてください。 MVELからgroovyベースに移行している
githubにも情報があるよ。 日本O'Reilly本でるらすぃ。
今後のビジョン
aggregationは今後に向けて、アナリティクスのプラットフォームとして躍進するのに重要な機能 ツイートが何百万もあって検索した場合ヒットが多すぎて一つ一つ追うのは無理。 aggregationがあれば検索結果から全体を俯瞰できる。 次のバージョンではaggregationがよりメモリ利用効率の高い形で実現できる。 さらにfiled-collapsionも実装予定（？）
resiliency?にも投資している luceneはハッシュの確認とかしないからデータの破損とか検出しづらい。 まずluceneにチェックサム検証機能を実装した、既にマージされている。 次のesではチェックサムを様々なステージで確認する。 シャードのマイグレーションとか。スプリットブレインとか。 より分散デプロイメントが安定するはず。
ペタバイトデータを持っている人が再インデキシングするとすごい時間がかかってしまうけど改善したい。
esのデベロッパはイノベーションに費やす時間を十分設けている 俺すごいの考えちゃった！なんてデベロッパがいればよしやれー見たいな風土にしている
Agile Japan 2014 いってきました（レポートというか個人めも）
Agile Japan 2014 レポートというか個人めも
とりあえず今あがってそうな資料まとめ
アジャイル入門
エンタープライズでもできるアジャイル開発
効果的に試行錯誤を行うための仕組みづくり〜失敗はおはやめに、プロダクトの成長は着実に〜
若干道に迷いながらも静岡から初参戦させていただきました。
一応、うちのプロジェクトではアジャイルな開発をしている。
「アジャイルな開発」っていう言葉
これはどうかなーって思うところはあるけどニュアンスとしてとらえていただければ。
自分が思う今プロジェクトのよくないところ
もちろんいいところだってたくさんある。
でも、あんまりうまく回っていると思っていないのが本音。
うちは複数のプロジェクトがアジャイルな開発をしていて、
自分のチーム・他のチームを見ていてなんかおかしいだろーって思うこと。
本当にエンドユーザに喜ばれるものが作れているのか？
なんでかっていうとフィードバックを全く得られていないから。
あっても要望に答えられていない （本来、ここが一番大事なはずなんだが・・・）
フィードバックを得るための方法もできていない。
プロジェクト内のどれだけの人が本質を理解している・しようとしているか？
わりとトップダウン的にアジャイルに取り組んでいる。
なので本質を理解せずに、ただただ終わりがない苦しい開発って思ったりしている人もいるのかなと思う。
チームが楽しそうに開発してない、悲壮感が漂っている時を見るのはとてもやるせない。
エンドユーザに喜ばれるのも大事だけど、プロジェクトが楽しく仕事できるっていうのも同じくらい大事なはずなんだけどなぁ。
まぁまるで成長しない、しようとしない自分たち自身がよくないが。。
開発・開発・開発・・・
日々の開発に追われてチームの技術向上の取り組みができていない。提案ができていない。
月に数回リリースするのがやっとな状態であったり、環境構築に何日もかかったり。
こんなことを続けていたらあっという間に世の中の技術についていけなくなってしまう。
技術ってアジャイルと密接だと思っていて、いかにコンピューターに任せられるところを任せるかが大事。
確かに初期構築までは時間がかかるけど、それに見合った効果はある。
リリースするのにチャットで「デプロイしてちょ。」っていうだけになれば
プロジェクトはユーザーが心待ちにしている体験を提供することに注力することができる。
最近まであんまり気にしてなかったんだけど、
「チーム開発実践本」やら「github kaigi」やらを見ていて、世間の動向ヤバス。と感じた。
今回期待していったところ
そんなこんなで今回 agile japan 2014 では以下の事柄について勉強させていただきたく参加した訳です
- チームビルディングのコツ、みんなで楽しく開発するために他社ではどんなことしているのか？
- 他社のアジャイルな開発、って実際にはどんなことしているのだろう？
- ・・・うち、技術的に遅れてる？
各セッションのまとめ
チュートリアル アジャイル入門〜オープニング
道に迷ったため、途中からの参加になりました。
内容は入門ーっって感じなので省略して、メモだけ。
- チュートリアル
- まず最初にとりくんでみるなら振り返りがおすすめ
→ その通りだとおも。振り返りの結果をどう積み上げていくかが難しい。。 - 実践して行動でしめす
- 「Social change statrs with you」
- 質問タイム
- 質問タイムの前に手を挙げる練習wこれは取り入れたいw
- (質)アジャイルでやりたいけどどうやって上司に説明したらいいの？
アジャイルという言葉を使わすに説明してみたらどうでしょう。 (質)まわりのひとを取り込んでいくにはどうしたらいいの？←質問させてもらいました
Agile Japanにつれてきたらどうでしょう。
→ 回答をもらった直後は「うーん」って思ったけど、水野さんの基調講演を聞いたら確かにいいかもと思った。
あれはYoutubeで動画を見るんじゃなくて、あの場で聞くことでより一層ココロオドルな。オープニング
- きっとスライドがあがるだろうと思って、数値系の話はメモしていない
- 2013年の禅の話はちょっと面白かった 自分がその場にたったとき、自分が感じるものを大切にする
基調講演：ソフトウェア開発者に問う ～日本人のモノづくりの本質とは～
水野 和敏 氏（元日産GT-R開発の総責任者）の講演。
すみません、車に興味がないので知らなかったです。。。
写真だけみて「ちょっと怖そうな人か？」と思ったけど、すごいめちゃくちゃ優しい物腰のお方でした。
まずメモまとめ
- 基調講演
- GTRという車は「日本のモノづくり」、「日産のモノづくり」ではない
- 権利はいらない、すべての責任をもらった
部門ごと分けるから責任をなすりつけあってしまう - 女子サッカー日本代表の話
個の強さではな到底勝てないが、チームの強さが勝っている
一人一人に役割を与えて、それぞれが海外などでその強さを成長させる - Raceを勝つために考えるとき「How to race」ではなく「What is race」で本質を考える
- BigDataから傾向を見いだして、それぞれのチームに目標を設定する
例えば、前回の大会優勝が６h３２mで、これまでの傾向から０h０２mタイムを減らせれば勝てると判断
そして車チームには1m10sec,ドライバチームには30sec,ピットチームには40sec
それぞれタイムを短くすることを目標にさせる - BigDataの分析結果、可視化したものは裁量や目標をみいだすためのマネジメントツール
- Try and ErrorのErrorはいらない、バカか！
このErrorってのは行き当たりばったりの失敗のことかな？
成功に着実に向かうための失敗を否定している訳ではないと感じた - 技術の進化が価格を下げる
- 会社という枠にはいると「会社が〜」「部長が〜」「他部門が〜」という言い訳を始めてしまうが、バカか！ 本来、社会的使命（What is）から職業を選んでいる。会社は手段(How to)でしかない
- 工程の最上流にあるもの、それは「現場」
現場が作れないものを設計してすごいだろっていっても全く意味がない。
現場の技術力があがらないと設計レベルはあがらない - 未来というものは言葉じゃなくて画像
言葉は過去を共有するためのコミュニケーションツールだ
いきなり討論するな、一人で考えた結果を画像で共有する - 目標を言葉ではなく、シーンで共有することが大事 例えば、「最高時速３００km」というものではなく、「海外の老夫婦が時速３００kmで３時間走りながら会話を楽しむ」みたいな
- 質問タイム
- 趣味で仕事をするから価値観が変になる
仕事は人のため、人の喜びを共有する
自分のために何かをしようと思うとアイデアはでてこないけど、人のためになにかしようと思うとアイデアは無限に出てくる 例えば、休日何しようかなーって思っても「疲れたから寝るかー」とかしか浮かばないけど
恋人のために何しようかって考えると「レストランにつれていうか」「ショッピングにいこうか」などなど、どんどんでてくる - ペルソナの設定論議には時間をかけるべき
- 最後に会場にむけて
会社の組織に埋もれるな、使命を果たせているのかが大事
でも、ダメでもともとと思って気楽に。失敗しても雇用した会社が悪いんだから（笑
もーーーね、これを聞けただけでも今日は agile japan 2014 きてよかったと思えた。
アジャイルの様々なプラクティスに当てはまるモノがある。
ペルソナの設定、個人で様々な案を図にして発表する、個々に役割を与える、ユーザーストーリーとかとか。
プラクティスはこういうモノづくりの本質から生まれているんだな。
だから、ただそれを実践しているだけになっちゃだめだと深く反省させられた。
youtubeの動画で見てるよねっていくつかスキップしてしまった部分があるからそこは動画を見ておこうと思う。
マイクロソフトにおけるアジャイル開発の実践
他社を見るということでセッションを聴講させてもらいました。
メモ
- 講演
- CEOがかわったらしい。
Mobile / Cloud / Usage / Engineer にフォーカス
Usage : いかに多くの人に使ってもらうか - VisualStudioOnlineのデモ
- 2005 → 2008?のとき、過去の負債（５０００件のバグ）を返済するために
４ヶ月間のMQ（マイルストーンクオリティ）を実施した
正直もっとアジャイルのお話をしてほしかった。
ほとんどの時間がVisualStudioOnlineのデモに費やされていて、聞きたいこととはずれていた。
ただうちもこういうリポジトリ、ビルド、テスト、デプロイのフレームというか
テンプレート的なモノをOSS組み合わせておいて、あらかじめ用意しておきたいなと思った。
新規でプロジェクトが発足するたびにやってたらちょっと無駄感。
あと最後の方でモバイルアプリのリリースの質問？みたいなのがあった。
ネイティブなアプリだと修正はいるたびにリリースはあり得ないんだろうな。
１日に何回も細かいバグがなおるたびにアプリアップデートとか使う方からしたら邪魔っちぃきがする。
効果的に試行錯誤を行うための仕組みづくり 〜失敗はおはやめに、プロダクトの成長は着実に〜
つづいてヌーラボさんの公募セッション。
水野さんの基調講演でTry and Errorはだめ！と言われてて、ドキドキしていたらしいw
講演見ていて思い出したけどBacklog作っていることろか。
メモ
* 講演
* パワポが黄色に白文字になっててなんにも見えないとこがちらほらw
* 2011年に３、４つの機能を盛り込んだビッグリリースに失敗。
２時間かけて前のバージョンに切り戻したらしい。
* UI設計にはコストをかけるべき。
UIドリブンな開発、開発者がなるべくそこに関わること。
そうすることで後々にいきてくる。
* UI設計ではモックを利用。
HTMLだけーのから、JavaScriptで動きがあるもの、ChromeExtensionをつかったものなど必要に応じて使い分けている
* 失敗できる環境づくり β環境
STGとは別に本番環境の横にいて本番のデータを使っている。開発者はそこを利用しているらしい。
切り替え方はバーチャルホスト・クッキーディスパッチ・リソーススイッチ・アプリフラグなどなど
* インフラはPacker/Vagrant/Ansible/serverspecを使っていてAWSを利用しているみたい
* アプリで使っているのはGradle
* nubotによる自動デプロイ
* 失敗するためには失敗しても簡単にやり直せることが大事
デプロイ失敗時のロールバックまで自動化
* だれが？どの環境が？デプロイ作業中なのかーっていうところは可視化してわかるようにしている
* フィードバックのためのトピックがあって「ツッコミビリティ」を確保している
情報をオープンに、別プロジェクトのメンバーもはいっていてそこからのツッコミも。
* フィードバックするときの注意
* ポジティブフィードバックを心がける
* 指摘ではなく提案をする
* 人ではなく課題にたいしてツッコム
* フィードバックしてほしいときの注意
* 見てほしいところを明確に、これみといてーはだめよ
* 手軽な場を作ること
* 質問
* データベースの構造変更はどうしている？
→ create table とかalter tableとかSTGで検証して問題ないことを確認したらやっちゃう
* どこまでのフィードバックに対応しているか？
→ 必要があれば利用者と直接会話して内容をきくことも。
自分たちで使い心地を判断しかねるときはβ環境を顧客にも提供する
β環境的なものは私たちも用意できている（キリッ
（最近アプリ適用できてないからいまいち感はんぱないけど）
でもすごいなー、やっぱり進んでるところは進んでるなー。
hubotで自動デプロイやりたいなー。
自動化するってことは試行錯誤を容易にするってことに通じるんだなー。
講演が終わってから、自動化をどうやって進めたかについて聞いてみたところ
一年間にわたって時間かけて徐々にやっていったので、
あんまり焦らず長期的な目で進めていけたらいいんじゃないかとアドバイスをいただけた。
あと誰が進めたかについても聞いてみた。こういうのは誰かがガンガン進めるべし、みたいなのもみたので。
そしたら割とチーム全体で進めていったご様子。素敵。
hubot使ってみたいんですよーと聞いてみたら、楽しいしおすすめですよと。
hubot自身でもいろいろできるけど、あらかじめあったJenkinsのジョブを実行するだけになっているらしい。
既存のリソースを無駄にしないでいけたところがよかったとのこと。
染田さん、貴重なアドバイスありがとうございました。
素敵なチームなんだろうな。
今更ながらどうやってチームビルディングしたか聞いてみたい。
twitterフォローさせてもらったので聞いてみようかしら。
アジャイル経験0から3年で3億以上を稼いだ道のり～とある中小ソフトベンダーの請負アジャイル開発実績～
請負というキーワードで聴講。
どうやってお客さんと調整しているのかしら。
メモ
- 講演
- リスクは承知で準委任ではなく請負
- 見積もりにはJUASの１画面１人月に０．７掛け（なぜかそう思ったらしい、ってのとお得感をだすために）
- どういう業務を実現したいのか→要件
- 要件定義はあくまで最初の指標としての立ち位置
- アジャイル初体験にしてはちょっと多めの１０人で立ち上げ
- メンバが楽しいっていってくれた → 大事
- 顧客も最初は少しずつのリリースに違和感を感じたみたいだけど、慣れてくるとどこまでできているのかが見えてよかったとのこと
- チームビルドは大変
- リリースの次MSを顧客の試用期間にすることでお客様の負担を減らす試み
- MS最終日はリリース、デモ、フィードバックの実施
- タスクは個人がこれやるーっていって選ぶ
- Geekがいてくれたことが大きい
- Geekレビューが必須で、負荷があがってしまっている、平準化が急務
- １つのアジャイルチームを２つに分けて、そこに未経験メンバを投入
- それぞれが気にして朝会やらチケットを見ていたみたいで、佳境時に別チームメンバにすんなり入ってもらえた
- 質問
- 調整系のおはなし
要求を一定に保てるようにしていた。
この機能があればこっちはいらないよね、とか。
顧客との協調が大事で、信頼関係が築けていれば請負でもあとあとで問題にはならない。
チームビルドやらメンバを楽しくさせる工夫とか聞きにいきたかったけど、既に捕まっていて聞けず。
UI/SSは全くやっていなくてコードから保守用のドキュメントを起こしているって聞いて「ほえー」ってなった。
やっぱりお客さんとの信頼関係大事だなぁ。お客さんも含めて１つのチームなんだよなぁ。
Embrace Change for Unchangeability. ～エンタープライズのためのアジャイル～
最後はここ。理由はなんかtwitterで見たことある人だったから。
メモ
- 講演
- 変化の中の不変の価値
- かわらないために動き続ける
- 開拓
- ３ヶ月かけてモノを作ったが、すべて捨てて２ヶ月で作り直したことも
- 一番最初に誰の何のためのITサービスかを書く
- プロダクトビジョンの検証
プレスリリースを書いてみる、壇上で発表もする
amazon?がやっているらしい。ヘビーユーザに見てもらってどう感じるか？など - ユーザエクスペリエンスデザイン
- ユーザにとって効率のいいタスクやナビゲーションフロー
- ユーザーインターフェースの見た目と雰囲気
- アイデアを反映したプロトでテスト
- ユーザがやりたいことが用意に達成できるか判定
- 持続（だっけ？）
この辺りでこれまでの情報量に頭いたくなってきているのでメモが少ないw
でもこの講演をしている人は徹夜あけで発表しているらし。
割とリアルなバーンダウンを見させてもらった。うちと似た感じのw
PullReq開発しているっぽくて、この人のレビューがOKになったらマージされるみたいだけどめちゃくちゃ大変っていってた。
そりゃそうだよな。。。
リリース自動化にも取り組みたいらしいけど顧客を説得させるための資料とかとかで取り組めていないらし。
まとめ
チームビルディングのコツ、みんなで楽しく開発するために他社ではどんなことしているのか？
こういう話はあまりきけなかったな。
でも情報の透明性は大事と結構多くの人が言っていた。その通りだと思う。
実際に別チームの人で「何も聞いてない」って言って怒ってる人もいるし
自分自身も定例会フィードバックでいきなり？？？な話を聞かされると「どうなってんの？」って思う。
tweetとか見てると、やはりコミュニケーションで困ってる人は多そうだ。
なにかできないか、もっと画策してみよう。
他社のアジャイルな開発、って実際にはどんなことしているのだろう？
うちの取り組みもなかなか悪くないではないか、と感じました。
ただマネジメント的な部分がイマイチなんだろう。
ほんとに、こういうセミナーにいってこいっていうのは「あじゃいるっ？」
って人に結構効果的なんじゃないかな。
・・・うち、技術的に遅れてる？
技術的に先をいっている所は先をいっている。
おそらく自社開発だからそういったところに融通がききやすいのかな？
うちもお客さんのメリットをちゃんと伝えたうえで
技術力アップのための検証とかさせてもらいたいから
そのために提案をしなければいけないな。
最後に
次回 agile japan 2015 も参加したい。
agile japanだけじゃなくて、もっといろんな所に参加してみたい。
水野さんの基調講演の動画がアップされたら(されるかな？)、部長に
みんなで見る時間をとれるか、みんなで見て意義があるだろうか
を相談してみよう。
Docker 指摘めも
sudo docker build sudo docker pull centos:latest sudo docker images sudo docker run -i -t centos /bin/bash sudo docker ps -a sudo docker start CID sudo docker stop CID sudo docker attach CID sudo docker rm CID sudo docker rmi IID sudo docker ps -a -q sudo docker rm `sudo docker ps -a -q` sudo docker ps -a sudo docker commit CID akria/nginx
Docker簡単にさわる
Docker
会社で環境を壊すという失態をしてしまったため、
Ansibleさんの自動化もすすめたいところだけど、ちょっとだけDockerさわってみることにした。
Macでのインストールはboot2dockerを利用する。
Mac直だとDockerさんは動かないみたい。
そのためboot2dockerさんで軽いVMをうごかしてその上でDockerさんを動かすイメージと認識。（あってるかな？）
インストール自体は超簡単
$brew install docker boot2docker
インストールしてみたもののどうなら勉強したいVagrant環境でやってみようとおもってそっちで進める
おまじないのようになってきたこいつ
$ vagrant init centos6.5 $ vagrant up $ vagrant ssh
公式サイトに従いながらインストール
sudo yum -y update sudo yum install docker-io
そして起動してみる。
pullはDockerイメージをダウンロードするためのコマンド。
ここではcentosの最新を指定している。
imagesはpullしたDockerイメージの一覧を表示するためのコマンド。
runはDockerコンテナーを実行するコマンド。とりあえずbashを実行する。
sudo service docker start sudo docker pull centos:latest sudo docker images sudo docker run -i -t centos /bin/bash
試しにテンポラリにファイルを作ってみて
bash-4.1# ls -l /tmp/ total 0 bash-4.1# touch /tmp/hoge bash-4.1# ls -l /tmp/ total 0 -rw-r--r-- 1 root root 0 Jun 22 08:10 hoge
ぬけて、もう一回見てみると、ふぁいるがない！
bash-4.1# exit exit [vagrant@vagrant-centos65 ~]$ sudo docker run -i -t centos /bin/bash bash-4.1# ls -l /tmp/ total 0 bash-4.1#
docker ps -aで確認してみると、２つのコンテナが作成されていたことがわかる。
気軽にらんらんしちゃあかんのかな。
[vagrant@vagrant-centos65 ~]$ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES eaefaadad338 centos:latest /bin/bash About a minute ago Exited (0) 6 seconds ago furious_thompson c2fe5ff7b502 centos:latest /bin/bash About a minute ago Exited (0) About a minute ago goofy_thompson
コンテナの削除はdocker rm PIDで、PIDは先頭数文字で消せるみたい。
[vagrant@vagrant-centos65 ~]$ sudo docker rm c2 c2 [vagrant@vagrant-centos65 ~]$ sudo docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES eaefaadad338 centos:latest /bin/bash 2 minutes ago Exited (0) About a minute ago furious_thompson [vagrant@vagrant-centos65 ~]$
とりあえずnginxでも入れてみる。
EPEL Repogitoryの追加が必要。
$ sudo docker run -i -t centos /bin/bash # rpm -i http://ftp.riken.jp/Linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm # yum -y update # yum -y install nginx
ちょっとさわった感想
Vagrantさんとの使い分けがあまりわかってないな。
CIとかでがんがん作って消してをするならこっちの方が良さそうというのはわかる。
何となくさわってみてイメージつかみやすいのはVagrantさん。おおもとはVMだから当然っちゃ当然かも。
AWSはどっちも使えるみたいだしなぁ。
