「DevOps的とは何ですか?」というテーマのブログを书くように求められるときは,他の方とは异なるアプローチで执笔することにしています。このブログでは,テクノロジー业界で过ごした长年の経験に基づいて的DevOpsについて定义したいと思います。プロフェッショナルとしての私の歩みにおける的DevOpsとの关わりについて说明し,その关わりが私と私のキャリアにどのように影响したかをお话します。

90年代

90年代半ば,インターネットはまだ黎明期であり,現在ほど,あらゆるものがつながり合っていませんでした。多くの人が,大切な人の連絡先情報を手書きで記した小さな手帳を持ち歩いていました。また,多くの人が,折り返し電話を要求するために使用されるポケベル(別名ページャー)を持っていました。情報は,定期刊行物や書籍などの紙媒体でのみ普及していました。人は図書館を訪れ,書籍を読み,インデックスカードベースのカタログシステムで資料を検索し,雑誌,新聞,または書籍を実際に開いて,必要な情報を得ていました。これは,アナログ時代の揺るぎない手動のプロセスでした。

私は1994年に职业としてプログラミングを始めましたが,テクノロジーを取り巻く环境は今日とは明らかに异なっていました。多くの企业は,テクノロジーの価値を认めてはいたものの,投资や采用をためらっているという微妙な立场にいました。当时,サーバー,CPU,メモリ,ストレージは非常に高価でした。帯域幅は不足しており,制限されており,非常に高额でした。多くのソフトウェア开発および运用(SREまたはシステム管理)チームは,アプリケーションおよび管理インフラストラクチャを手动で,さらに重要なこととして,别々に,开発,テスト,およびリリースしていました。データセンターは,适切な电力供给,温度制御,配线を设计,构筑,実装し,すべてを管理できる有能で熟练した担当者が常驻し,高価なインフラストラクチャハードウェアを设置する必要がありました。小规模なスタートアップ企业から巨大な企业まで,すべてが何らかの形の「データセンター」を利用していました。

当時の私のソフトウェア開発は次のような業務でした。

  1. 个别にコードを记述する
  2. 「新规保存...」の方法で,新しいコードのバージョンを作成する
  3. 手动でコンパイルする
  4. アプリケーションを手动でテストする(通常は,ポイントアンドクリック,サブミット,结果の検证というプロセスを缲り返していました)
  5. コードレビューはほとんど行っていませんでした
  6. デプロイ用のリリースパッケージを手动で作成する
  7. パッケージのリリース/インストールノートを作成する
  8. フロッピーディスク,CD,またはネットワークファイルの共有ディレクトリを介して,リリースパッケージを运用チームに提供する
  9. 待ちぼうけ

新しいリリースの结果を待つには,4时间から10日间がかかっていました。この时间の长さは,运用チームの忙しさと,新しいリリースをデプロイするオペレーターのスキルに依存していました。开発者と运用チーム间のコミュニケーションはほとんどありませんでした。実际,ほとんどの开発チームと运用チームは反目していました。チーム间ではソフトウェアの品质(テストされていない,またはテストカバレッジが不十分)に対する深い不満があり,本番环境へのソフトウェアのデプロイが迅速に行われないためにこのような敌対が発生していました。

キャリアを積むにつれて,開発チームと運用チーム間における不要な敵対を引き起こす要因について熟考する時間が増えていきました。熟練した技術があるスタッフがいるこれらの非常に有用なチームが,同じ目標とミッションを達成するために効率的で一貫して作業する方法を見つけられない理由を,私は理解できませんでした。開発チームと運用チームがまったく連携していないことは明らかでした。両方のチームには,ソフトウェアを本番環境にリリースするという1つの目標がありました。この目標以外について,問題を解決するために協力することに関心はありませんでした。このテクノロジーの時代には,開発者と運用者の関係は分断されており,悪影響を受けており,有害な文化が生まれていました。もちろん,これはすべてのチームや組織に当てはまるわけではありませんが,ここで説明したような悪しき文化の何らかの形で,ほとんどのチーム/組織に存在していたと思っています。

アジャイル

自分が取り組んでいた業務への姿勢,考え方、文化について簡単に理解してもらうために,自分のキャリアの早い段階におけるソフトウェア開発者としての経験を説明しました。当時の素晴らしい思い出を美しく描いているわけではないことは自分でも分かっています。まったく異なる経験をした方もいるかもしれませんが,私が経験したような機能不全について多くのチームも同感してくれるのではないでしょうか。

时间が経ち,テクノロジーが进化するにつれて,机能が向上した安価で高速なハードウェアと広い帯域幅が利用できるようになりました。また,开発チームは,ソフトウェアの开発方法を向上しました。开発チームは,プロセスを彻底的に分析し,ソフトウェア开発ライフサイクル(SDLC)のボトルネックを特定しました。また,ソフトウェア开発プロセスを変更し,チーム间のコミュニケーションを改善することにより,高品质なソフトウェアを迅速に提供できることに気付きました。多くのチームと组织が,アジャイルソフトウェア开発の概念の采用と実践を开始しました。これにより,开発の问题を理解し,新しい方法论と戦略を生み出す新しい概念とアイデアを取り入れることができるようになりました。これらのアジャイル手法では,コラボレーション,顾客フィードバック,小规模で迅速なリリースを中心とした,反复的なアプローチが采用されています。

さまざまな開発チームや組織と一緒に数年間,アジャイルの原則を採用しながらソフトウェア開発の運用を成功させ,チームが以前よりもはるかに迅速にコードを生成していることに気付きました。開発者は,コード上でオープンに協力しあいました。そこでは複数のチーム間でコードを作成,変更,共有を可能にするバージョン管理システムが重要な役割を果たしました。時間の経過とともに,開発チームはさらにスマートに作業を進めることができるようになり,高品質のコードを作成する時間が劇的に短縮されました。コードは高速で記述,テスト,およびパッケージ化されていきました。開発チームはフル回転し,コードが高速で作成されていきましたが,予期しない問題が発生し悩まされることになりました。開発中の新しいコードは,作成されるようなペースでは迅速にリリースされなかったのです。これは,リリースまたはデプロイプロセスを十分に考慮することなく,ソフトウェア開発プロセスの改善にのみ注力していたためでした。そのため,顧客にリリースできていない新しいコードが溜まっており,開発者にとって非常に大きな問題となっていたのです。

DevOps的との出会い

自分が书いたコードは,いつでも気にかけており,自分のコードを「谁が,どのように,何を,どこで」使用するのかについて非常に兴味を持っていました。私は,この好奇心を満たすために,运用チームと良好な关系を筑かなければならないことを分かっていました。キャリアの早い段阶で,私は,开発チームと运用チームは共存关系にあることに気づいていましたが,他の开発者と运用担当者も,自分と同じ考え方を共有していると素朴に思っていたのです。しかし,现実にさらされたとき,私は闭口しました。これらのチーム间に「障壁」がある理由を本当に理解できませんでした。私はこれらの「障壁」は,开発チームと运用チームがそれぞれの帝国を作って守るための言い訳ではないかと考えるようになりました。また,これらの2つの组织の间にあったこの障壁が,イノベーションを抑制する大きな要因になっていると考えていました。この问题を认识してから,私は常に自分のことを「运用侧よりの开発者」と呼ぶようになりましたが,これはなかなか言い得て妙であったのではないでしょうか。

运用チームとの基本的な连携机能が欠如していることによって,アジャイルの取り组みよって得られたすべての恩恵が完全に无に帰していることに気付いてからは,システム开発ライフサイクルに运用(OPS)を组み込む新しい戦略を作り上げるために,チームを结成しました。このときにはまだ,DevOps的という用语はありませんでしたが,この言葉に宿る精神は,そのときに,アジャイルを采用および実践した开発チームの中に确実に存在していました。多くの「アジャイル」チームは,同じように困难な状况下に置かれていました。开発チームは,ソフトウェアを迅速に开発するようになっており,実际にコードを本番环境にリリースするときに大きな障壁に直面していました。

開発者の何人かの同僚は,運用チームとの私が良好な関係を気づいており,その関係を活かして,両方のチーム間の橋渡しをするように提案しました。私は,自分に災いが降りかかること,折角運用チームと築いてきた関係を危険にさらすことを若干懸念していました。開発チームの権力闘争と誤解される恐れのあるアイデアによって,関係を傷つけたくありませんでした。そのため,この急進的なアイデアによって運用チームにアプローチする方法について,長い間懸命に考えました。頭の中で何度も会話をリハーサルしたことを覚えています。そして,対話の準備ができたと思ったときに,運用チームとの打ち合わせをスケジュールしました。不安は,打ち合わせの日が近づくにつれて大きくなっていきました。

ついに,その日にやってきました。私は,自ら作った台本(何度もリハーサルした)に基づいて会话を始めました。本当に惊いたのですが,运用チームのマネージャーは,私に话をやめるように言った后で,运用チームが开発チームと同じスピード感で歩调を合わせるためにはどうしたらよいのかと质问してきたのです。このマネージャーは,开発チームが调整,品质,速度を向上し,成功を收めていることを,运用チームは见てきたことを说明しました。彼は,また,运用チームが,现在のプロセスがソフトウェアリリースを高速化するための大きな障害になっていることを认识していることも伝えてきました。これが运用チームの立场であり,运用チームは开発と运用のプロセスの両方を改善するために开発チームと喜んで协力したいと闻いて,私は本当に大喜びしました。

そして,単纯でも简単でもない「障壁を打ち破るため」のジャーニーに取り组むことになったのです。両チームが理解して受け入れることができるリーンアジャイル戦略を考案することが,私たちが克服しなければならなかった最大の障害だった记忆があります。开発チームはすでにアジャイルを取り入れており,アジャイル文化にシフトしていたため,开発チームが运用チームに提案をするときに,ある意味で上から目线だったのかもしれません。开発チームの自信は,利己的と认识されました。この状况と,人の敏感性を考虑し,闻き手の心を闭ざしてしまうような伪善者なトーンを最小限に抑える方法で,お互いの问题を解决するために役立つコミュニケーション戦略を迅速に磨きました。チーム间のコミュニケーションのレベルを上げることは,壁を打开するときの最も大きな课题だと感じました。コミュニケーションの问题を改善する方法を取り入れた后には,开発チームと运用チーム全体は,别の部门として,そして単一の部门としても机能できるようになり,ソフトウェアデリバリの业务を同期化することができました。

時が経つにつれて,開発チームと運用チームのインタラクションが改善され,最終的には,過去にあった機能不全が解消されました。チームはお互いに信頼し合うようになり,極めて高い効率化を実現できました。開発者は,開発プロセスとスタックのパラダイムに関連する詳細について運用担当者を教育するようになりました。運用担当者は、開発者にリリースのプロセスとインフラストラクチャのメンテナンスにおけるチームの役割について詳しく教育していました。これらのチームの統合に向けた変更は、一度に行われたわけではありません。時の経過とともに変化が進んでいきました。文化の変化が成功した理由は、双方のチームが同じように努力し、試行錯誤を繰り返して、向上するための方法を学んでいったことです。私たちのチームは、コミュニケーションと透明性がもたらす利点を学びました。それにより、各部門の役割と、部門がプロセス全体にどのように影響しているのかを明確に把握することができたのです。

DevOpsとは何か吗?

“DevOpsという用語が生まれる前に,私たちのチーム間では真のDevOps文化が生まれていました。数年後,DevOpsという用語を初めて聞いた後,瞬間的に,それが何を意味するのかわかりました。DevOps的という言葉は,我々が成し得たことを言い表す最适な言葉でした。

では,DevOps的の私の定义を読者の皆さんにもお伝えします。

DevOpsとは……

  • コンセプトである
  • マインドセットである
  • 个人が理解し,受け入れる共通した姿势である
  • 育成し繰り返し改善する必要がある文化である
  • 共有することである
  • メンタリングすることである
  • 学習することである
  • インクルーシブであらゆるアイデアにオープンなことである
  • 反复的である
  • 継続的である
  • コラボレーティブである
  • 自信を持ってソフトウェアを開発およびデリバリするための素晴らしい方法である

DevOpsとは……

  • 简単に达成または実装できることではない
  • 制品またはツールチェーンのひとつではない
  • 役職や役割のひとつではない
  • ひとつのクラウドインフラストラクチャプロバイダーではない
  • ひとつの书籍ではない
  • ひとつのテクノロジーではない
  • ひとつのプログラミング言语ではない
  • ひとつのマーケティングキャンペーンではない
  • CI / CDではない
  • Kubernetesではない
  • コンテナではない
  • オープンソースソフトウェアではない
  • コードとしてのインフラストラクチャではない
  • オートメーションではない
  • 軽々しく扱えるものではない!

结论

最初に述べたように,自分の数十年に及ぶ経験に基づいて,DevOps的についての自分の见解を绍介しました。私の过去の経験を読んでいただいたことで,新しい视点で的DevOpsを捉えることでき,的DevOpsの必要性と的DevOpsが组织にもたらす価値を知っていただく一助となることを愿っています。自分の経験を思い出し,それを皆さんと共有することができ本当に楽しかったです。

最后まで読んでいただき,ありがとうございました。