改善 DevOpsチームは、ソフトスキルを設計する「DevOpsチームのエンジニアはソフトスキルが必要」の前に、あなたが記事を見ることができます
「フェニックス・プロジェクト」であり、コンテンツが小説の形が、本を読むの分野ではまだアジャイル開発とDevOpsチームではあるが、DevOpsチームコミュニティ神の本。多くのよく知られたコンサルタントが、この本のDevOpsチームによって開かれており、本の中で機敏な旅の物語は、毎日の仕事の運用・保守に由来している、生命の本質よりも、生活から芸術の現れです。2年の著者の間隔は、二回の本を読んで、私はあなたが他の人に学んだ本の中でいくつかの経験を話すことができると思います。
ビルの主人公、一時的に引き継いだ、しかし、この時間をIT運用管理者の位置を、同社は、常にいくつかのレイオフのラウンド、生産ラインの障害を経験してきました。取締役会は、フェニックスが会社を救うために、プロジェクトを再起動することを期待しますが、直面する困難の層は、ビルは肉体的にも精神的に疲労し、突然の断層線に対処するために停止するようになりました。私たちは、伝統的な開発モードからの移行、多くの意味、小説の内容がまとめた、ピットの多くを踏んとして生き残るために、企業の通常の操作では、企業のIT変革プログラムの設定を試してみてください、全体のプロセスは開発モードのDevOpsチームの変換のようなものです私は素晴らしい物語は、以下のあなたが本の重要な教訓のいくつかをまとめて与える、書籍の購入に直接行くことができます理解することが、唯一の物語と多かったです。
4つの作業の1.フォーム
物語の中で、ヒーローがでビルを成功 ITマネージャ、トラブルシューティングや対人コミュニケーションプロセスの一連の、私たちはこの結論に達しました。ITの仕事は、より多くの次の4つのタイプよりも何もありません。
- IT部門内のプロジェクト
- ビジネスグループプロジェクト
- 変更作業
- 消防の取り組み
実際には、仕事の四種類以上の当社の運用・保守部門の現在の状態と一致して、我々は開発およびテスト事業に参加するために、自らの運用・保守および監視プラットフォームを開発する必要があり、我々は、インフラストラクチャとアプリケーションのバージョン変更やアップグレードのすべてをする必要があります。そして、これらは、通常の仕事の一部であり、私たちはしばしばに対処するために最も消極的な操作を消火され、このような突然の故障につながるラインなど、すべてのユーザ機能を使用することができない、多くの場合、技術的な運用・保守担当者になります VP、CTO、さえの最高経営責任者（CEO）次の行を見ていると、問題を解決するには、コマンドラインをノックしました。運用・保守要員の大多数は振り返ってみると、似たような経験を持っている必要があり、我々はこの火を低減するための作業、作業の最初の3つの合理的な配分を持っているので、ひどいされている必要があります。
2.、変更管理を強化燃焼挙動を減らします
ITの4つのワーキングフォーム、我々は2つの法律サークルの運用・保守に見てみましょう、火の挙動を軽減する方法、問題が出てきます
有名な8つの法則：行の80％から障害の変化の20％。
GoogleSRE理論：についての変更のいくつかの種類の展開により、事故の70％がトリガされます
我々はないもつれん 80％と、アプリケーション、データベース、オペレーティングシステム、ネットワークやハードウェアなどの変更の結果差の70％を生産する方法であるが、結論は統一され、断層線の多数の変化によるものです、物理的、論理的または仮想オペレーティング。私たちは、それはラインの故障を引き起こす可能性があり、通常はこれらの変更は、リスクの高い業務に対処するためである理由運用・保守容易なスケープゴート、コンテンツカバーに、運用・保守作業の多くを見ることができます。部外者、運用・保守は、消防業務、トラブルシューティングの開始後、困っています。状況の種類を避けるために、どのようにそれを処理するには？記事では、障害が発生しても、非常に重要な方法は、すべての後、かんばん方式、すべての変更の標準化された管理、計画の変更を使用することで、すべての変更は、リスク評価のポイントをもたらし、私たちを与える、それはすぐに修復することができます。
3.個人のヒロイズムを避けるため、技術的準備金を強化します
小説の故障によって引き起こされるすべての変更を解決するときに、大切な人、デュLunteがありました、これは運用・保守チームの英雄的な役割で、彼は問題を解決していません。しかし、すべての開発者はそんなにので、彼は変更を加えることのために、すべてのシステム障害は、彼と一緒に対処する必要が探しているように、このような強力な人物であること、毎日消防作業に従事している人。この役割は、私たちは次元の標準化プロセスを出荷し、ボトルネック点となります。限り、彼の作品は、他の人に置き換えることができないように、我々は彼が運転・保守チームは、このような、そのような重要な建設を監視して、ビルディングオートメーションなど、より重要なことを、やらせることはできません。小説は、この問題を解決するために、ビルは、デュLunteが保護、開発者はドゥLunteをデュLunteと直接通信し、他のエンジニアデュLunteオリジナル作品との接触を手配し、してみましょうすることはできませんが、トラブルシューティングの分類メカニズムを設定しましたビルディングオートメーションと建設の監視に重点を置いています。このような技術的準備金のキーの位置が増加するだけでなく、最も重要な位置で使用されるコア技術スタッフ。
4. 製品の限られた数から行う（かんばん）の数を減らす、0 1 0.5〜
やっとの三年間はあまりにも長い間準備コースのライン上のプロジェクトは、大きな動きを我慢した後、「フェニックス・プロジェクト」と呼ばれる小説、フェニックスプロジェクトにコアの周りストーリー公転の名前は、フェニックスプロジェクトは、3年間のプログラムです。最後に、このプロジェクトは、失敗にそれを教えてくれるかの質問を終えました。ヒーローの工場の床には、WIPに影響を与え、工場労働者が固定されている場合は半製品があまり蓄積された場合、それは我々がソフトウェア開発の分野で言っていたものである、遅くなり顧客に納入最終製品につながることを実現するために、配信の速度は、同じ時間あまり需要の反復的な開発チームは、その後、ニーズがユーザーの手にあっ送達されなければならない場合は、時間を延長します。だから、製品の数が制限 DevOpsチーム建設のコア要素、我々は0-1やるべき事を、そして減らす 0.5の数を。会社への現金の返還せずに一年以上のR＆D資本半完成品の形でロックされ、彼は会社のために完済することはほとんど不可能になると本は、非常によくまとめています。
仕事の3段階法
最後に、新規な3ステップの加工方法まで、著者の合計であって、
1） フロー原理
フロー原理は、 DevOpsチームのインフラと潜在的な顧客のニーズを満たすための時間を短縮し、ビルド自動化ツールチェーン、手動での介入のプロセスを削減、製品の数、迅速な反復を減らし、効率的に作業と生産の品質を向上させることができます。
2）フィードバック原理
ソースで問題を発見し、早期に問題を発見し、テストし、左の安全性、生産のソースで品質を確保するために必要です。
3）継続的な学習と実験原則
生産性は、促進するため、リーダーシップに上昇ワークフロー着陸DevOpsチームの文化を。
概要：あなたは「フェニックスプロジェクト。」、それを見るために本を買って、待っています
私たちのオンライン教室を集中するために、よりエキサイティングなコンテンツ
マイクロチャンネル公衆番号を検索：コースの通知を取得jfrogchina