タグ

ブックマーク / infras.blog.jp (9)

  • インフラで実践したチームビルディングそれはサバ天 : インフラエンジニアに成る

    スクラムにあこがれて。 インフラで実践したチームビルディングそれはサバ天 from ume3_ カンバンをやってカイゼンをしたというお話です。 ここ1年ぐらいずーっとリーダーとして チームビルディングに勤しんでいた。 チームを強くするにはどうすればいいか? チームでわいわいやるにはどうすればいいか? 簡単な話、仕事ってどうやったら進むのか? それをつきつめていった結果、なぜか特異な結果が生まれた。 なんだこれは。 社内に共有したものをせっかくなのでこちらへ公開という流れです。 モザイク多いのは勘弁。 これでも、けっこう内容けずったのです。 やっていることは、ホワイトボードの前で付箋紙はってわいわいやっているだけ。 スライドでは説明不足ですが、サイクルがちゃんとあって ぐるぐる回すことでチームが加速化するのが狙い。 見える化の力を今も実感しています。 こういったフレームワークの活用からの発展

    インフラで実践したチームビルディングそれはサバ天 : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2014/11/20
    梅さんのブログを最近みてなかったけどこんなの書いていたのか。みんなで考えた上でこういうのにたどり着くチームビルディングいいなぁ~シブ知とかインパク知とかネーミングのマトリックスも、まんまアレだww
  • Monitoring Casual Talk #2で発表してきた : インフラエンジニアに成る

    モヒカン族とカジュアルに。 @studio3104と@nakashii_さん主催の Monitoring Casual Talk #2で発表してきた。 てか、全員発表タイプ。 会場につくとそこにはステキな張り紙がお出迎え。 帰り際にこの紙をいただいたので、会社のモニタの裏に張ろうと思う。 自分の発表資料はこちら。 資料はどうでもよくて、議論がメイン。 疑問をぶつけて、自分はこうしていて、 で、みなさんはどうしていますか?ってのをお話した感じ。 資料からは、全く伝わらないのは仕様です。 リリース後の監視項目について話をするのが目的。 設定を元に会場のみなさんにやさしくつっこんで頂き大変勉強になった。 議論に臨場感が出て思ったより話が盛り上がってよかった。 以下、つっこみ。思い出しながらまとめ。 ■SSL証明書のチェック間隔の話 ・15日前にアラートとかだと、けっこうばたばたしないか? ・もっ

    h5y1m141
    h5y1m141 2012/11/09
  • 開発者にむけてDevOpsな現場で求められる「インフラがわかるデベロッパ」とは? というテーマで話してきた発表した話 : インフラエンジニアに成る

    テーマはDevOps。 Devが語るDevOpsはあふれておりますが、 Opsが語るDevOpsってないよね!っていうのが話の発端です。 この発想にいたった企画者の人がまあすばらしい。 いつも、お世話になっております。 DevLoveはあるのにOpsLoveはないよってことですよ。 すごいねこの視点。 それにのっかり、今回お話する機会を得ました。 結論としては、Dev and Opsでやっていきたいねという話! 懇親会も大変もりあがりとても有意義な時間を過ごせて楽しかったです。 自分の発表内容に不安もありましたが、よかったよの一言をいただけて自信になりました。 以下、つらつらと。 いつものように覚えている言葉を文章化。 ・プログラマの時代。コードの時代。 2012年感じるのは、ほんとプログラマさんの時代だなって思います。 ツールはどこからくるのかといえば、Dev。 それにのっかるOpsとい

    開発者にむけてDevOpsな現場で求められる「インフラがわかるデベロッパ」とは? というテーマで話してきた発表した話 : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2012/09/28
    凄いトライアスリートがアイアンマン・ディスタンス目指す一方で普通の人向けにオリンピックディスタンスあるようにすごいor普通のエンジニアが目指す道が様々あってもいいかな。その道がどんなものか言語化できない
  • DevOpsな現場で求められる「インフラがわかるデベロッパ」とは? という題目でセミナーをやるというお話 : インフラエンジニアに成る

    というわけで、人前でしゃべります。 ・DevOpsな現場で求められる「インフラがわかるデベロッパ」とは? 日時 : 2012/09/27 19:00 to 21:00 来てほしいな層はこちらのリンクからだけど、 一般枠もありまして、ATNDでの登録はこちら。 facebookもあるよ。 内容のメインとなるところは説明より以下、一部抜粋。 なぜ「インフラがわかるデベロッパ」になるべきか? デベロッパと密接に係わるインフラエンジニアの視点から、「なぜ、インフラがわかるデベロッパになるべきなのか?」をWeb開発の現場動向を交えながら考察します。 今回は、キャリアなお話。 現場の技術なお話+キャリアのお話の組立を予定しています。 とりあえず、DevOpsとはいっているけど、Devな開発者向けのお話ですね。 コンセプトがおもしろいかなーということで挑戦してみます。 DevがDevを語るのではなく、

    DevOpsな現場で求められる「インフラがわかるデベロッパ」とは? という題目でセミナーをやるというお話 : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2012/09/03
    "コンセプトがおもしろいかなーということで挑戦してみます。 DevがDevを語るのではなく、 OpsがDevを語るという視点がお話の趣旨になります。" そういってもらえると、お願いした側としても嬉しいですねー
  • Automation Tech Casual Talks #1で発表してきた。 : インフラエンジニアに成る

    Puppet使って構成管理を自動化したときにDevOps意識したよーな内容。 さて、おもったより#autotechcasualでつぶやきまくっていたので思い出しながら以下、つらつらと。 第2回開催時の参考になればと思います。 先にまとめ。 ・インフラ視点の話が中心 ・ChefとPuppet使っているけどどうなの?な話 ・Jenkinsチラチラ ・AWS使っているお話ちらほら ・DevOpsの意識 このあたりに興味あるかたには非常に意味のある集まりになったかと思います。 僕は楽しかったな〜。 ※ 資料はアップに気づいたら随時追加しております。 ■@n0tsさん 主催者が先頭きって発表。 「ぼくがかんがえたさいきょうの☆きっくすたーと☆」はたしかに最強だった。 cobblerのkickstartでどこまでできるかがテーマ。 githubにまとめてあげているのがすばらしい。 ただ、3年ほど使用し

    Automation Tech Casual Talks #1で発表してきた。 : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2012/07/18
    お、そういえば、@ume3_ さん、 Automation Tech Casual Talks #1 参加&発表してましたね。
  • 【セミナーやるよ!】エンジニアの日々の学習についてお話しませんか? : インフラエンジニアに成る

    今度こそ。 ということで、おまたせ?しました。 また、キャリアセミナーのパネラーを やりますのでよろしくお願いします。 〜アウトプットにも繋がる、エンジニアの日々の学習について〜 2012/02/08(水) 19:00〜21:00 今回は第1回のときのお話を元に そもそも、アウトプットする前に日々のインプットってどうしているの? という視点でお話を展開できればなと思っております。 お気軽にどうぞどうぞでよろしくです。 前回中止してしまい、楽しみにしていたかたもいるみたいで申し訳ありません。 今回はきっちりやりますよ。 新年早々でもないですが、今年もよろしくです。

    【セミナーやるよ!】エンジニアの日々の学習についてお話しませんか? : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2012/01/27
    "【セミナーやるよ!】エンジニアの日々の学習についてお話しませんか?" こっちでも告知してもらった
  • hbstudy#6に参加した : インフラエンジニアに成る

    インフラエンジニア勉強会に参加した。 hbstudy#6。 第6回目は監視についてだった。 他の会社は監視ってどうしてるのかな? ってのが気になったので参加。 以前のSI屋のときの監視とは違う 今いるWeb業界の監視のノウハウをお聞きできれば ってのが狙い。 あと、前後半とわかれていて後半はLT大会だった。 5分と短い中でいろんな話が聞けた。 ためになる話ばかり。 また、うんうんわかるわかるとうなずくことも。 以下、メモ。 <前半> 対応しない監視は誤報と同じ ・定例業務と非定例業務で監視は定例。 ・監視:情報収集活動。高可用性。 ・監視は機能監視と性能監視に分かれる。 ・機能監視:L1〜L7。ツール:Nagiosとか ・性能監視:CPU・I/O。ツール:muninとか ・最近は、オープンソースのツールが充実 - Hobbit、Nagiosなど。 ・監視のポイント(参考になる) - ログ出

    hbstudy#6に参加した : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2009/12/07
    hbstudy#6のまとめエントリ。"対応しない監視は誤報である。"というのが印象に残った
  • 自作サーバカンファレンスにいってきた : インフラエンジニアに成る

    土嚢(どのう)を忘れない。 自作サーバカンファレンスにいってきた。 とにかく満足度の高いカンファレンスだった。 みなさん一人一人のプレゼンがうまくって 聞いているだけでかなり楽しいお話。 ほんと、内容が濃かった。 それも5社分も聞けるなんておいしい。 USTREAMでの配信もあったけど、 会場に足を運んで正解でした。 体験談を直接聞くことができたのは大きいですね。 質問もできたので満足。 目に見えないリスクがたくさん潜んでるはずなんだけど それに挑戦してかつ楽しんでやっていのがすごい。 今回の話を聞いて自分も自社に 自作サーバー導入したいなーと感化されました。 注目度も高かったのか参加者が多かったです。 それだけに、このカンファレンスに 参加することができてほんとよかった。 50人枠から100人に増えてラッキーでした。 来年も自作サーバカンファレンスするらしいんで そのときがほんと楽しみで

    自作サーバカンファレンスにいってきた : インフラエンジニアに成る
    h5y1m141
    h5y1m141 2009/11/26
    自作サーバカンファレンスの感想やまとめ。ume3参加出来て良かったですね。
  • コミュニケーション能力なのか技術力なのか : インフラエンジニアに成る

    以下のどちらの能力がネットワークエンジニアにより求められるか? コミュニケーション能力(以下、コミュ力) 技術力 こういう話がよくある。 どちらが大事なのかと考えた場合、 全体を10と割り振れば"何対何"になるのか? どちらにかたよりがでるのか?と、以下考えてみた。 エンジニアと名がつくからには技術力でしょ と思うところだがそうでもない。 日々、技術的な作業を過ごすとは限らないのがネットワーク。 対人とのやりとりだけで1日が経過することだってある。 そうなると、コミュ力0に対して技術力10とは割り振れない。 逆に、技術力0はありえるか。 対人関係に全時間を注いでいれば コミュ力10が必要だになってしまいそうだがそれはない。 対人の先には必ずネットワーク技術がからんでくる。 技術なしを前提としたコミュニケーション方法として 会議・客先の打ち合わせ・電話・メール・書類作成 といったすべてが成り

    コミュニケーション能力なのか技術力なのか : インフラエンジニアに成る
  • 1