DevOpsDays 2013マウンテンビューの印象

会議はほんの数時間前に終了したため、受信した情報の量と質に関してはまだ少し混乱しています。 この投稿を書くことで、自分の考えを理解できることを願っています。 最初に、一般的な印象があります。次に、レポートを簡単に確認し、会議で議論されたものについての考えで終わります。そのような考えの利点は、コースで適切に蓄積されています。 DevOpsの世界で彼らが話していることを知りたいですか？ それからあなたは猫の下にいます。 そして、はい、投稿は長くなりますが、最終的にボーナスのサプライズがあります）。



すぐに言いたいことは、エンジニアがエンジニアのために行った会議であり、エンジニアだけがそれについて話しました。 OpsCodeやPuppetLabsなどのベンダーツールの代表者の間でさえ、マーケティング部門や営業部門から退屈することはありませんでした。 それが彼らに対して適切な態度があった理由であり、彼らは彼らと頻繁にそしてしっかりとコミュニケーションを取りました。 同じ理由で、ボディペインティングによって描かれたミニスカートには女の子や人はいませんでした。 これらすべてが、熱ランプ会議の本当にクールな雰囲気を作り出しました。 ちなみに、そこには約300人がいましたが、これはあなたが望む誰かとのコミュニケーションを止めることはありませんでした。 一般に固体陽性。



会議の形式について個別に説明します。1部屋、4レポート、10〜15分間の6回のイギナイトトーク、そしてオープンスペースです。 この形式のため、すべてが非常に動的であり、誰もがすべてのレポートを取得することができました。最も重要なのは、現時点で本当に関心のあるトピックについて話し合う機会があり、「私たちがしていること」のカテゴリからの次のレポートを聞かないことですところで、1つはありませんでした。



また、本当に重要なことにも注目したいと思います。エンジニアリング会議では、20のレポートと講演に火をつけましたが、ツールに専念したのは2つだけでした。 それ以外はすべて、プロセス、文化、慣行、および人々に関するものでした。 私の耳に心地よいこと-二日間で誰も人のリソースと呼ばれませんでした。 私たちも同じだろう！



それでは、レポートを見ていきましょう。 プログラムはこのリンクで利用できます。レポートとビデオはしばらくしてから中央に配置されますが、レポートに戻ります。



会議は、元消防士であり、互換性のためにOpscodeの共同設立者であるJesse Robbinsから始まりました。 ジェシーは、誰にとってもかなり単純ですが、残念ながら明らかではないことについて話しました-devopsへの移行、これはビジネスの必要であり、エンジニアが自分の立場に接頭辞を付けたいという欲求ではありません。 そうでない場合は、問題が待っています。 一般的に、Jesseはアジャイルとdevopsの値を使用して企業を変革することについて話しました。 そして、大企業がどのように近代的で高性能な組織に変身しようとしているのかについての彼のレポートの重要なアイデア。 会社は象であり、変革の目標は飛ぶことを学ぶことだと想像してください。 そのため、多くの企業が象の耳を振って離陸しようとしています。 結果は想像できます。 飛行方法を学ぶには、翼、適切なエネルギー、離陸する場所が必要です。 したがって、そのような企業を本当に価値のあるものに変えるには、長くて複雑なプロセスであり、翼を成長させて過剰な体重を減らす必要があります。 私にとって、この報告書は、devopsの真の本質を反映していたため、会議全体を通して重要でした。



Jesseの後、この言葉はJeff Sussnaに伝えられました。JeffSussnaは、 devopsでのQAの役割はどこにあるのかについて語っています。 一言で言えば、QAのタスクは、お尻から頭を出し、申し訳ありませんが、見始めることです。そして、最も重要なことは、実際の世界と実際のユーザーの視点から、そして戦闘システムでのアプリケーションの操作だけでなく、ビジネスワーク。 概して、正しいQAはアジャイルでも同じことを行う必要がありますが、devopsでは、彼はまだインフラストラクチャを理解し、配信の自動化について検討する必要があり、先駆者のコーナーや機能テストだけではありません。眠っているテスターを起こそうとしているのは別の人だからです。



休憩後、 J。ポールリードはマイクを制御し 、組織について話しました。 この組織は、FAA-連邦航空局、連邦民間航空局であり、アメリカ国内で同じ12万便を毎日正常に完了しています。 ポールは、FAAが行うことと開発プロセスをどのように構築するかについて、素晴らしい類似点を描きました。 同時に、開発者はパイロットになり、オペレーションはディスパッチャになります。 このような多くのプラクティスを追加します-システムに動物園が来た場合、どのルールを設定しても、正直に認めてそれを作り上げます。 そして、これはすべてのチームメンバーに共通のタスクです。 そして、動物園があまり頻繁に発表されないように、私たちは事後分析を行います。 報告書では、ポールは、アメリカ全土に嵐が襲った状況と、当時の飛行機の挙動をフェデックスディスパッチャーがどのように処理したかについて、クールな視覚化を行いました。 視界は印象的です。 スライドを待っています。



最初は、女の子がITに参加できるようにするために彼らが思いついたものについて話していたので、私は4番目のレポートをでたらめだと感じました。 このプロジェクトはhttp://www.hackbrightacademy.comと呼ばれ、とてもクールですが、スタッフのメンタリングや採用などのトピックを提起するまで、私はそれについて知りたくありませんでした。 そして、それは本当にクールなトピックであり、それが理由です。 多くの企業では、従業員の雇用の問題は深刻な問題ですが、同時に、人々を既存のプロセスに統合する方法について十分に考えていません。そして最も重要なこととして、チームが持っているのと同じ価値観を彼らに伝えます。 そのため、この問題の解決策はメンタリングであり、正式ではありません。私はメンターです。大丈夫ですが、従業員の時間が割り当てられている本格的なメンターです。 そして重要な要素は、実際のトレーニングだけでなく、価値の移転、望ましい考え方への調整です。 このようにして、人々は本当にチームに統合されます。 また、「あなたのJr. エンジニアは、将来それをどのように適用するかを知っているのです。」一般に、多くの企業は注意を持っています。



私は詳細な発言については書きません。ビデオを待って見てください。本当にクールなレポートがありました。 脳が爆発した）



レポートの2日目は、主催者の一人であるDamon Edwardsから始まりました。DamonEdwardsは、会社でdevops文化を構築する方法について話しました。 プレゼンテーション全体は非常にクールですが、1つの主要なアイデアを強調したいと思います。 製品を適切に提供できる会社になりたい場合は、チーム全体に会社の発展と収益の方法を理解してもらいます。 また、損失、ファカピットなどがあります。 これを行うには、Value Stream Map（タイムライン分析と無駄分析の両方を行う必要がある）とメトリックツールチェーン（ビジネスから社内の各エンドパーソンまでのメトリックのチェーンを構築する）の2つの便利なツールが手元にあります。 最終的には、誰もが会社が市場でどのように生活し、利益を上げるかについて、それぞれの役割を理解する必要があります。 #devopsトレーニング中も含めて、devopについて話すときは、これらのことを伝えようとします。 そして、「私たちのプログラマーの時間はそのような会議に費やすには高すぎます-彼らはコードを書かなければなりません」、「プログラマー/テスター/管理者はそれを知ってはいけません。 -リソース。 あなたが最後のグループに属している場合、私はあなたのための写真を持っています。











Damonの後、 Toufic Boubezが 、監視などの重要なことに触れ、＃monitoringsucksタグが長い間積極的に使用されてきた理由に触れました。 したがって、監視ツールを自分で設定し、ガイドを取り、その上ですべてを構成しました。 モニタリングはありますか？ フレヌシキ！ 大量のリソースを消費し、誰もが緊張するシステムがあります。 したがって、レポートの非常に単純な考え方は、メトリックのいずれかが分析されない場合、炉に送信する必要があるということです。 これを防ぐには、システム内のイベント（デプロイ、再構成、新機能のリリースなど）ですべてのメトリックをリンクする必要があります。 それをしないでください-あなたの監視は吸う！ 2番目の単純な考えは、ガイドラインに盲目的に従うのではなく、JVM、CPU、ディスクI / Oなど、システムに害を及ぼすものの最初の1-2メトリックを構成することです。 そして、あなたは幸せになります。



その後、尊敬されるThoughtworks社（ Scott Turnquest ）からの仲間からの報告がありました。開発プロセスが鈍くて遅い場合、参加者だけがそれを改善できると言いました。 これを行うには、後視ポイントを上げ、Value Stream Map、Ishikawaダイアグラム、またはルート問題の解決策を見つけるための少なくとも5つの理由を構築する必要があります。 いつものように単純に聞こえますが、私自身の経験から、多くのプログラマーは、コーディングしないで集会に行くという単なる考えに揺れていることを知っています。 主題の写真。











Antoni Batchelliからの最後のレポートは、私たちは実際に複雑な世界に住んでいると言っています。 しかし、これは私たちを止めるものではありません。また、複雑なソフトウェアを作成し、それをさらに複雑なインフラストラクチャに配置し、それをすべての方法で長い間見過ごしています。 アンソニーが最後に言いたかったこと-複合語の反意語は簡単ではなく、単純です。 もちろん、これは翻訳不可能なしゃれのように見えます。 簡単に言えば、すべてをこのように表現することができます-複雑であることが保証されていることをする前に、小さな兄弟、つまりあなたと一緒にあなたと一緒に働く人について考え、それでもそれを使いやすくしますわかった。 実際、レポートは複雑であり、情報の2日目にはまともな以上に受信されたため、もう一度聞き直したいと思います。



次に、私の頭の中にあったものを要約しようとします。 ITの現在の状況では、顧客が必要としている必要なソフトウェアの提供を開始し、これに最善を尽くすか、実際に負担をかけずに競合他社に絞られます。 キャプテンからの考えは明らかですが、全体のポイントは「これに全力を尽くす」というフレーズにあります。 これが意味することを明らかにしようとします-クールなアイデア、賢い開発者、おせっかいなマーケター、裕福な投資家を見つけるだけでは不十分です。 これは一括で有効です。 重要な考え方は、すべてが、より正確に、たとえそうであっても、すべてが相互に透過的に機能し、互いに必要な理由を理解する必要があるということです。 次。 アンソニーがすでに述べたように、私たちは生き残るために多くの精神的な努力をする必要がある驚くほど複雑な世界に住んでいますが、このためには時間を必要とします。 だから、この異端と提携する時が来ました。さもなければ会社はカペトし、履歴書を更新する必要があります。 これは実際、よく知られているフレーズ-「理解できない状況では-進化する」を意味します。 つまり、新しいプラクティスを学び、プロセスを自動化し、文化を変えるなどです。 これを行うのが面倒-さよならを言って、すぐにこの市場から尋ねられます。 これについてはコメントで議論したいと思います。



雰囲気を和らげるために-最も印象的なツイートのいくつか。

しゅう

愚かな戦いをしないでください。 もっとすごい。 <-単語。 ＃ devopsdays ＃ cloudops



@ adrianco

象は耳を強く羽ばたいて飛ぶことができません- @ jesserobbins ＃ devopsdays



@ jonathan_thorpe

「価値の共創は旅です。」 もっと同意できませんでした。 どんなに些細なことでも、サービスのすべての側面が＃devopsdays



@ dberkholz

QAの新しい役割：製品を超えた全体的なユーザーエクスペリエンスについて考える。 サービスを提供することです。 - @ jeffsussna ＃ devopsdays



@ ウィケット

サーバーは農場の動物のようなもので、子供たちに名前を付けさせるのはもっと難しいです＃devopsdays



@ kylesj <

ビジネスの「理由」以外に「理由」はありません。 ＃ damonedwards ＃ devopsdays 。 うん。 クールなもの！=ビジネス向けの配信



@ writerferret

ペンと紙の力を過小評価しないでください。 あなたはいつも派手な技術を必要としません＃DevOpsDays



@ jondecamp

「人々がコンピューターにできることをするとき、すべてのコンピューターは夜遅くに集まり、私たちを笑います。」 ＃ Devopsdays



@ ベンゾボット

「複雑さが妨げになったときに、再構築または再設計することを恐れないでください。」賢明な言葉！ ＃devopsdays



@ vmwarecloudops

「問題の複雑さを軽減し、抽象化の層を構築することで問題を解決する必要があります。」 ＃ DevOpsDays



そして今、約束されたボーナスの時期-今年9月にモスクワで（またはサンクトペテルブルク、まだ終了が決定されていません）、DevOpsDays Russiaカンファレンスが開催されます。 私はそのオーガナイザーを務めますので、ご期待ください！