Clever Geek Handbook

エンタープライズおよびファイナンスのDevOps。 火星に生命はありますか

アーティオムカリチキン（CFT）



アーティオムカリチキン（CFT）



私の名前はArtyom Kalichkinです。私は金融技術センターで働いており、銀行および金融セクター向けのソフトウェアの生産と開発で主導的な地位を占めています。 私は運用サポートのディレクターです。



企業環境でDevOps、CDのプラクティスとアプローチを使用することは可能ですか？ どのような機能がありますか？ SPARC + Unix（Solaris）？ 垂直スケーリングと、その結果、バトルとステージでの異なる構成。 これについてお話します。





原則として、会社の生産構造には2つの部分があります。





なぜ私はこれについてすべて話しているのですか？ これらの製品の意味、運用および保守の観点からの機能は、これらの処理サービスにフルサイクルを提供することです。 私たちはそれらを開発します-私たちはアイデアを考え出し、開発し、私たちの施設、データセンターにそれらを設置し、実際、すべての運用運用と保守を提供します。



このような金融セクターでの搾取と保守と呼んだこのことはどのようなものですか？ 実際には次のようになります。







これが私たちの現実です。 これが私たちの人生です。 ここで具体的なものは何ですか？ これは、本番環境と本番環境の厳密な分離です。これは、ログなどのアクセスがまったくないことです。 具体的には、いくつかの条件付きDMZを介して、開発者向けの（そしてエリート向けの）ログのみを送信します。 絶対に生産セグメントは開発のため閉鎖されています。



この写真のパフォーマンス特性は何ですか？ データセンターにある機器として、オラクルのサーバー、つまりSPARCベースのサーバーが使用されています。 X86ではなく、これは別個のSPARCアーキテクチャ、Solarisオペレーティングシステムです。 これは金融サービスであるため、幸いなことに、物理学者はこれらのサービスを24時間年中無休で使用しているため、稼働時間とシステム操作の要件は24時間年中無休で4で、5つあればクールです。 同時に、この会議のコンテキストに関連しない何かがあります-Oracleで書かれたビジネスロジックの多く、ほぼ90％があります。 Oracleで記述されていることを言うと、そう、これらはOracle DBMSにあるPL / SQLコードのパッケージです。 したがって、ビジネスロジックの約90％が実装されます。 したがって、いくつかの喜びは単純なスケーリングに関連しています。 さらに、これらの巨大なサーバーはすべて垂直方向にあり、水平方向にはありません。 これがすべての機能です。



すでに述べたように、24x7、4ナイン、PL / SLQコード...そして、非常に狭いリンクを持っています-ダウンタイムなしでシステムを更新することはできません。 システムを下げ、海岸でアップデートを実行してから上げなければなりません。 ロシアでは、すべてのタイムゾーンで作業し、これを行います。クライアントトランザクションの最小数が通過するウィンドウを選択し、このウィンドウにシステムをダウンタイムします。 この時間帯は、ノボシビルスク時間の午前1時から2時です。 この時点で、管理者は実際に夜に出かけ、アップデートをバトルにロールバックします。



彼らはどうやってそれをしましたか？ これはWordのドキュメントでは非常に汚いトリックです（その後、Confluenceに切り替え、別の機能もありました）。その手順では、バックアップ、ここにコピー、ここにコピー、アップロード、設定ファイルに移動、設定などを行います次に、パラメータをベースに移動し、パッケージの無効化をチェックします。パッケージが無効であること、すべてが正常であることを確認します。 つまり これは手動の指示です。 配布はファイル共有を介して送信されます。 大まかに言えば、「web_new_new」を投稿するので、彼らは間違いなく新しいものをピックアップしますが、管理者は深夜に「web new_」からそれを取得します。その結果、ある種の間違ったもの、つまり中間バージョンが展開されています。 つまり このような戦闘システムの更新サイクルでは、エラーの深byが避けられないことは明らかです。



当然のことながら、更新に問題が発生した場合にこの状況全体を保証する重要な開発者が勤務していることは明らかです。 原則として、夜間の作業の前に、そのような条件付き戦闘/手動のドライランは、戦闘1に対応する特定の参照コンプレックスで行われ、管理者は日中の指示に従ってこれらすべてのアクションを実行します。 これだけが本番ではなく、完全に類似した複雑なものです。



最初に対処したこのような過酷で見苦しい画像。 同時に、私たちは私たちの周りの全世界を見て、スタートアップを見て、DevOps mitapsを見て、私たちの環境から見ると、この条件付きの世界は上のスライドのようなもののように見えます。 対照的に勝利。 つまり 私たちの現実はあなたの現実です。 これを見て、あなたは思う：なぜ、これはなぜですか？ しかし、答えは私たちが望むほど明白ではありません。



少し実験してみます。 おそらく誰もがMasterCard、Visaなどを持っているでしょう。 みなさんがGazMyasBankから発行されたカードを持っていると想像してください。あなたはGazMyasBankのクライアントです。 したがって、マスコミおよびメールで届いたアナウンスから、GazMyasBankが最近、かなり若い攻撃的な金融グループAyDaParniによって購入され、銀行がAyDaBankに改名されたことがわかります。 その後、約1か月後、銀行からあなたに宛てたこのような流行に敏感な公開レターを受け取ります。 文字通り次のように書かれています：「こんにちは、セルジュ！ 夜間にゲームを切ることが多く、午前2時以降はさまざまな支払い取引を行うのが大好きであることを知っています。 緊急の支払いが必要な状況、非常にストレスの多い状況、または非常に辛い時期にならない状況がいかに愚かであるかを完全に理解しています。 したがって、私たちは時代の精神に合わせてあなたに会うことにしました、要するに、私たちのすべての処理サーバー、カード製品のデータを持つすべてのサーバーは、手術室をよりアクセスしやすくするためにAmazonのクラウドにあります」 この手紙の翌日にあなたの行動は？ 誰がこの銀行からお金を取らないのですか？ そして、誰がこの銀行からお金を取りますか？ なぜ拾わない人がいるのか分かりません。 どうやら、実験として。



ちなみに、運用会議とdevops RootConf 2015および2016で公開されているビデオを公開しました。 YouTubeアカウントの 2015年と2016年のアカウントの関連シートを次に示します 。


重要なのは、金融や企業で働くとき、私たちはあなたの個人データ、銀行の秘密に直接責任があることを忘れてはならないということです。もちろん、最も重要なのは顧客であり、最も重要ですが、中央銀行、規制当局、関連する国際機関へ。 これは単にあなたを喜ばせたいという私たちの願いではなく、単に必要なことです。 私たちは特定の規範と要件を順守する義務があり、それらの非遵守はライセンスを取り消す恐れがあります。 条件付きで、中央銀行には支払いの完全性に関する要件があります-クライアントがあなたにお金を与えた場合、あなたはこの金額をさらに処理するために彼の注文を履行しなければなりません。







したがって、この質問に対する答えは明らかではありません。 AyDaBankのメンバーのようになり、ちょうどそのようになることはできません。次のようになると、ライセンスはすぐに取り消されます。







しかし、それにもかかわらず、これらすべてのテクノロジーに直面していた私は、私たちが確実に利益を得ることができると確信していました。 はい、すべてを行うことはできません。理想的には完全な組み立てラインを行うことはできません。戦闘で簡単に実験し、柔軟に、動的に試すことができる人になることはできません。 いずれにせよ、我々はいくぶん不活性で、十分に官僚的で、一貫して厳しいままです。 しかし、私は私たちが利益を得ることができると確信していました。 そして、私の会社でこれらのアイデアを宣伝し始めたとき、私は「オールオアナッシング」症候群と呼ばれる抵抗に遭遇しました。



このシンドロームは、「まだDevOpsを完全に使用できないので、何を試してみるべきですか？」または「1つの製品を別の製品にするために何を始めますか、そして何が重要なのか、フットウェアからすべてを取り出し、構成しますとにかく、大まかに言えば、今はできません。」 つまり 「オールオアナッシング」の原則からの膨大な数の異議。 ほとんどすべてのSkrumトレーナーが、Skrumを完全にフォローしているか、Skrum-0を持っていることをオーディエンスに証明するとき、これはすべて、Skrumを教える原則の1つを非常に思い出させました。しかし、Skrumに関しては、少なくとも、おそらく、このプロセスの深い決定論、すべての要素の強力な相互接続のために正当化されます。 しかし、一般的に、他のすべてにおいて、私はこのアプローチに同意しません。 何も真実ではありません。 私たちの質問に対する100％の答えはありません。 常識の穀物を分離し、それらを実装する必要があるすべてから。 私はこの意見に至り、私の同僚に銀の弾丸が存在すると確信させることができました。







銀の弾丸は、銀の弾丸を継続的にキャストしなければならないことだと思います。 あなた自身、あなたの経験、あなたの常識、あなたの脳は特効薬です。 つまり 実際、素晴らしいエドワードデミング、継続的な改善のプロセスは、唯一の既存の有効で実績のある銀の弾丸です。



さて、私は抵抗のこの段階を通過しました。IT部門と同僚の両方に、私たちはこの道を行くことができると確信しました。 しかし、次の質問が発生します：なぜですか？ 私たちは20年にわたってこのように生き続けており、市場で主導的な地位を占めており、すべてがうまく機能し、顧客がサービスを使用していますが、なぜあなたの変更が必要なのですか？ なぜ私たちの生活の中で何かを変える必要があるのですか？ ここでは、かなりグローバルなトピックに関する個人的な考察を許可します。 トマトとその他すべてに同意します。 しかし、私は、さまざまなケースを分析して、そのようなビジョンに到達しました。







プロジェクト管理には古典的な状況があります。 品質、時間、価格はありますか？ そして、古典的なプロジェクト管理は次のように語っています。「友よ、3つすべてを提供し、2つを選択することは不可能です。3番目の要素が苦しむという事実により、それらを保証します。」 そして、最近までそうでした。



スタートアップの精神がまだソフトウェアの開発に普及し始めるまでは、リーン生産の精神は普及していなかったと思います。 リーン製造の技術とアプローチにより、この問題、このジレンマを別の平面に変換し、1つの次元を追加できるためです。 この測定値は何ですか？ これには、製品の機能がいっぱいです。 そして実際、彼らはあなたが別の言語を話すことを可能にします。



無駄のない製造、製品を立ち上げるための無駄のないアプローチ、スタートアップについて話している場合、3つのうち2つを選択することに疑問の余地はありません。 彼らは3つすべてを取り、尋ねる：「他に何をする必要があるのか​​？ さあ、私たちの手は燃えている、私たちはまだしたい。 他に何？」



何のため？ もちろん、ソフトウェアは飛行機ではないという事実のために、それは重いエンジニアリングではありません。 ソフトウェアを作成することで、未完成の飛行機を飛ばすことができ、また飛ばなければなりません。MVPを上げる必要があります。 今日、同僚はニューヨークからの会議から戻った、彼らは新しい傾向があると言います-MVPからMVPをします。 原則として、しっかりとしたアプローチ。 そして、これらすべてにより、このジレンマから逃れることができます。 そしてこれは、私たちが彼女を離れなければ、競合他社が彼女を離れ、彼らが私たちを簡単に追い越すことを意味します。 私たちが座っている間、私たちは巧妙に昔ながらの方法で目立ち、「まあ、それはうまくいきました」と言います。 このようなジレンマがあることを知らない若い企業は、リーンスタートアップの精神で行動し、3つの条件をすべて満たして、一部のセグメントで私たちを迂回します。 しかし、まったくそうではありません。 しかし、徐々に少しずつ動き回ります。 今日はできないこと、明日は競合他社がやることです。 これは、私の観点から、質問に対する主な答えです。なぜ変更する必要があるのでしょうか？ 市場に留まり、質の高い実績のある金融サービスを引き続き提供したい場合、私たちには権利がありません。無駄のない製造技術、DevOps技術に変更する義務がありますが、私はアジャイルについては一切語りません。







「ネオ、青、赤の丸薬を選択してください。」 赤い錠剤を選んで飲んだ。 そして、私たちが夢見ていたDevOpsに移行することに決めたとき、私たちはその虹の世界にはいませんでした。 そして、私たちが考えていたピンクのポニーは、私たちを攻撃した血に飢えたモンスターであることが判明し、非常に長い間それらを撃退しようとしました。



私たちが遭遇した小さな問題について簡単に説明します。







ここで、3つの鋭いポイントは、3文字のロシア語の取り消し線です。 厳密な分離の詳細のため、私たちは決して夢を見たことがなく、根を夢見たこともありません。 人生でそれを受け取ることはありません。 私たちは彼を必要とせず、人形は彼を必要とし、私たちは何もしないと主張して、これを非常に長い間戦いました。 しかし、これは最終的なものであり、議論の対象ではありません。



したがって、Solarisだけでなく、Solaris 10th、つまり 現在のバージョンは最新の11.2で、Solaris 10があります。 その下の製品を収集することは、別の地獄と痛みです。 これらすべての依存関係、すべてこれがダウンロード、収集、バイナリからのコンパイル。 私の意見では、1か月のシェフがSolarisで独自に編集したことは知りません。 とても長い間です。



3番目の質問。 長い間、二元論、つまり これは非常に重要なタスクでした-ファイル共有を介して配布パッケージを転送することは避けなければなりませんでした。これはエラーの底なしのソースであるためです。 常に誰かがこのボールからいくつかのアーティファクトをクリーンアップせず、どこかでそれをひっくり返し、ディレクトリの名前を間違って付けました。どんな慣習が受け入れられても、ジャムはそうなります。 したがって、ファイルボールを残すことは基本的に必要でした。 ソリューションとしてパッケージマネージャーを選択しました。 パッケージマネージャー、IPSフォーク、IPSバージョンを使用しました。 彼は、そうであったように、私たちがした第10回で、第11回Solarisにいます。 彼らにはクロスプラットフォームのIPSプロジェクトがあり、私たちはそれを分岐し、10番目のSolarisの下で組み立てました。 別のwhiもありました。 ただし、それでも、IPS、パッケージマネージャーを介してディストリビューションを配布しています。 私たちはこのように進んでおり、私たちはそれに満足しています。



攻撃はありませんが、Gitのリポジトリにバイナリを保存しようとすることは、私にとって非常に奇妙なことです。 Mavenについてはアイデアがありましたが、彼はそうではありませんでした。 それでも、パッケージマネージャーにはより多くの機能があり、同じレシピと課題に関してより多くの問題を解決します。 つまり これはより広範なソリューションです。 私たちはここで正しい道を進んだと信じています。



そのような機能に気づいた-RubyはゆっくりとSPARCアーキテクチャに取り組んでいます。 つまり x86と比較して、私たちがやらなかった、やらなかった...原則として、この情報は神聖なインターネットで確認されています。 確かに、アーキテクチャの特殊性のために...そこにあることがわかりました-多数の弱いプロセッサがありますが、それらはたくさんあります。 そして、この話では、コードはx86プラットフォームよりもはるかに遅く実行されます。



達成した時点で停止することなく更新します。 私たちは多くの点で大きな進歩を遂げましたが、すべてではありませんでした。 これについて詳しく説明します。 サーバーに新しいApacheが必要な場合は、「新しいApacheをデプロイする」というリクエストを作成します。 私たちは問題なく入場して展開できますが、不可能です。 「新しいApacheインスタンスをデプロイしてください」というリクエストを作成しています。 管理者が時間をとってから1週間待ってから、Apacheが提供された瞬間にユーザーを取得するのを忘れていたので、Apacheを提供してくれます。 最近、トムスクの人たちは座って、「なぜ？...」と考えました。 apacheが2週間にわたって発生した理由を論理的に説明することはできません。説明することもできません。 そして、残念ながら、これは私にとって苦痛のままです。 また、将来的にはこれから離れたいと思っていますが、これまでのところ、手動​​で環境を準備しています。 しかし、ポイントは、垂直方向のスケーリングがあることです。水平方向はありません。そのため、ちょうど近づいています。 したがって、毎日ノードを作成するわけではありません。通常の環境をロールするために50個の新しいノードを作成するタスクはありません。存在しないため、これまでのところそれほど苦痛はありません。



もちろん、チームの問題、パーソナライズされた戦争について考えるとき、私は少し後で停止します。 彼らは始めました：「これは私のものです、これはあなたのものです。」 プロジェクト段階のある時点で、2人の双子のフリーク兄弟、Div DevOpsとOps DevOpsを呼んでいます。 2つの並列パイプライン、並列スタック、並列ソリューションを作成しました。 Opsはまったく気分を害し、Ops DevOpsを作成しました。 Devは、「なぜ彼らを待つのか、私たち自身がDev DevOpsを書いた」と述べました。 そのような写真。



どういうわけかそれを傍受し、解決する必要がありました。 決定したとおり、後で説明します。 会議では、何を使用するかを最初から最後まで明確に理解できるツールチェーンは聞いていませんでした。 おそらく、この答えは存在しません。 私たちはまだ自分自身のために決めていません、すなわち シェフ企業は私たち、人形としての選択肢として適していないので、私たちは本当にいくつかの質問があります。 パペットにはいくつかの製品があり、パペットを展開しています。 シェフの製品の一部。 一般に、これは私たちが出くわしたゴミの一部です。さらに、私たちはこれを予期せずに出くわしました。したがって、これに直面し、何をすべきかわかりません。 、Solarisを正常な状態のままにします。」 そのような解決策は私たちには適していないので、この意味で、私たちはある種の孤立状態にあり、「叫び、刺されたが、サボテンを食べ続けた」。 これは世界の写真です。







これはどのように起こりましたか？ 一般に、2013年にプロジェクトを正式に開始しました。 次の重要なタスク、目標を設定しました。 私たちにとって、午後に更新できるすべてのものを午後に更新することを学ぶことが重要でした。 つまり ダウンタイムなしの更新、ダウンタイムなしの更新。 毎晩の更新は粉であるため、人々は過熱しているため、これらはチームの大きな社会問題です。 kosyachnik開発者が何かを台無しにしているために、日中にパッチをパッチするために管理者が必要な場合-これはそれほど悪くはなく、管理者が夜間にこのパッチをロールアウトする必要があるときいくつかの超大規模な憎悪、ただの黒い憎悪。 したがって、夜間の更新を最小限に抑えるために、これは非常に重要なタスクの1つでした。



タスクはさらに-夜間の仕事にアプローチすること（日中の仕事にも、しかしまず第一に夜間の仕事に、全員がそこにいるわけではないため）、私たちがすること、リリースに含まれるもの、セットに完全に理解することリリース作業。 なんで？ 最初の段階で、DevOpsの前でさえ、ITILを実装したいくつかのケースがあったため、それはリリース管理の一部でした。 私は次のように言います。「みんな、夜の仕事の前に開発者と操作を集めて、彼らが夜に何をするかを話し合ってみましょう。開発者だけが静かにすべての質問に指示を出しました-すべてがそこに書かれていますか、あなたは何ですか？ そして、それら-よく、彼らは指示を書く方法を知りません、彼らはすべてを理解します、我々は一般に、何も理解しません。」 そして、さまざまな方向に分散しました。



まず、私たちは集まり、夜に何が起こるかを話し合うことを学びました。 なぜこれが重要なのですか？ これはすべて機能しない可能性が高いためです。 おそらく、夜に何かがおかしくなります。 そして、許容範囲の限界を理解するために、それにもかかわらず、すべての作業をロールバックすることを決定した場合、ロールアップ後にログに記録されたこれらのエラーは許容可能ですか？ それらは有効であるかもしれませんが、そうではないかもしれません。そのため、私たちが何を行っているかを理解する必要があります。 したがって、私にとって非常に重要でした。



そして、戦闘状況を知ることは理想的です。 論理レベルでかなり分岐した複雑な戦闘展開スキーム...多数のトランスポートサービス（私はトランスポートと呼びます）、特定のJavaモジュール、さまざまなニュアンスや質問に責任を持つ膨大な数のユーザー...そして、いくつかの変更、修正、パラメーターの変更は常に行われ、そして、事件の時点で、私たちのこの巨大な軍事インフラ全体が今だという明確な理解を常に持っています。 これを確実にする必要がありました。 そして、DevOpsの前に、私は実際にITILのCMDBを実装しようとしましたが、構成管理プロセスを正常に実装し、原則として、後で検証されなかった誤った変更に関連するインシデントの数をゼロに減らしました.CMDBは必要ありませんでした。



もちろん、これは官僚的なかすであり、作業を行う必要がある場合は、どこかで実行し、Apacheで設定したパラメーターをそこに反映します。 ここでは反対から必要です。 私は、一般に、DevOpsのこのため、やがて夢中になりました。 HighLoadの同僚が私のところに来て、「聞いて、彼らはそこで構成管理システムについて話します。DevOpsのように見えませんか？」 Chefについて読んで、これは間違っていると思います。インフラストラクチャを制御する必要があり、レシピでそれを変更します。 しかし、それから私は制御したくない、制御された方法でインフラストラクチャを管理したいという理解が来ました。それが私の仕事です。 したがって、私は戦闘状況を完全に知りたいです。







そして、そのような主要なタスクを上位レベルの目標のフレームワークに設定します。 つまり 戦いと開発で同じ展開パターン。 私たちは異なっていました、すなわち 戦闘で、大まかに言って、1つまたは別の相互作用ロジックを担当する30のJavaモジュールがあった場合、戦闘ではすべて1つのモジュールでした。 そして、開発者が現実のバージョンで思いついたものがまだ戦闘スキームに対応していないため、戦闘への撤去中など、競合を引き起こす他の多くのそのような違いがあります。



少なくとも、構成を管理するまで環境を準備しないタスクを設定しますが、フットクロスにデプロイせず、レシピをデプロイし、人間的にデプロイできるようにします。



すでに述べたように、ディストリビューションの配布、ダウンタイムなしの更新、可能なすべてのこと、これらの夜の仕事を離れてこの憎しみを取り除く必要があるため、人々が互いに通信することは不可能です。 物理的に人々は互いに通信できません。 開発者と運用-私たちはそれらを同じフロアに強制的にまとめるステージの1つです。 それは恐ろしいステージでした。私たちは長い間その準備をし、決定し、決定しました。 それも丸ごとの歌でした。







今日は何がありますか？ この間に何を達成しましたか？





, :







? , , , , , , - , , enterprise , , .







. , .







このレポートは、Operation Conferenceおよびdevops RootConfでの最高のスピーチの1つのトランスクリプトです。



, , — RootConf 2017 — 5 6 .



, " ", , …



Kubernetes



Kubernetes production . «» Kubernetes , . , , : , Docker , «» (Marathon, Rancher, Kubernetes)… - !



Kubernetes ( 50 ), :



  • , Kubernetes ;
  • , ;
  • , CI/CD ( GitLab dapp) ;
  • すべての（私たちが知っている）賛否両論を整理して整理することで、プロジェクトがKubernetesを必要とする理由の質問に答えようとします。
  • そして最後に、落とし穴の位置とサイズに関する情報を共有します。




これらの記事は私たちのブログで6か月後にあなたを待っています:)まあ、または1か月でRootConfカンファレンスで、そのプログラムが好きなら:)



More articles:


All Articles