アリの姉妹REVIEW：2015年末までに、アリは台湾で戦略的アリババグループの立ち上げを発表しました。時間に沿って、より革新的なDT構築の柔軟性「中規模および大規模のユニット、小受信」組織機構と動作機構：戦略は以下のように定義されます。その中でも、フロントデスクファーストライン事業として、より機敏で、より迅速に市場に適応する、ステーションはリング内のテーブルレイアウトで非常に重要な運用能力のセット数、製品の技術的なグループ全体の容量、様々なビジネスの見通しのための強力なサポートの形成とグループになります台湾は、技術上の探索ユニットは、製品が世界クラスの挑戦を満たしているように、の検索ではあるが、理由は複雑さと検索技術自体のビジネス上の課題の規模の。

課題は、アリは統合運用・保守プラクティスの開発段階では、道路に着手することを選択しました。どのようにどのようにこのルートを移動するには？ここではアリシニアテクニカルエキスパート検索課劉ミン、一緒に仕事を理解するために従ってください。

背景

アリは早期の心臓段階を検索し、より機敏なフォアグラウンドのビジネスをサポートし、より迅速に市場の変化に適応することで、ビジョンは、世界を作ることです検索を使用することは困難ではない、我々はDevOpsチームで3年間、3年間、早期の心とビジョンに基づいて0-1建設から駅を探します、AIOpsは、降水オフラインプラットフォームのリーディングエッジ上の業界がたくさんある、と私は、検索のベテランアリとして、台湾で検索全体アリの技術開発を目撃することができたので、ここであなたと私の個人的な経験のいくつかによって制限されていますどのように前方のプラットフォーム製品に向けた大規模、コスト、効率、品質、経験を解決するためのバックエンドサービスを共有することができます。

台湾での技術開発を検索

その下の図ではなく、三年以上の練習の過程を着陸した後、検索トレンドにおける台湾の技術的な観点からの判断です。

私はアリに参加したとき、最初の段階でなければなりません私たちは、検索部門やオープンソースの検索技術の両方が、システムの運用・保守・運用を担うことが人に依存している、チャートから見ることができます。その時の人的資源で人的資源を大量に消費し、作業の非効率的な重複を行う際に、このステージの人工制御している間に、ビジネスの成長、などの規模に正比例しています。

降水量との経験の後、PEは徐々に、いくつかの一般的な繰り返しの運用・保守作業は運用・保守の効率を改善するだけでなく、予備的な専門知識やドメイン知識沈殿影を持って、ある程度の人件費の削減、自動化スクリプトを使用して達成することができましたこれは、自動化されたスクリプトの運転・保守のステージ、オープンソース技術システムの大半となっている段階です。しかし、この方法では、自然に開発・運用・保守の両方の役割の維持管理を分割します。

我々はすべての障害のほとんどは実際にオンラインであることを知っているので、二つの役割は、希望の反対の自然、高速で反復的な開発にできるだけ安定したとして保証運用・保守ラインが反復回数を削減するという希望が立っていたので、みんなの異なる使命なぜなら、これを固定し、毎週火曜日と木曜日のリリースウィンドウのリリースが、次の2つの側面が、最終的な妥協点を持つことになりますので、自然の原因部門への設定変更およびソフトウェアのアップグレードので、互いの反対側の不信感があります前提条件として、業務運営の効率を犠牲に。

実際には、ここで操作して、新しいビル制御システムの統合概念のDevOpsチーム開発のメンテナンスに基づいてこれらの矛盾を解決するために、反復的なシステム機能とビジネスニーズの片側に大きなギャップがあるされて入ってきた、と開発の第一段階を持っています運用・保守一体化建設のでなく、反復リリースOPSを通じて、これらの問題のいくつかを解決しました。

しかし、私たちのビジネスシナリオの管理と制御が自然技術システムである、我々はDevOpsチームを定義したいので、DevOpsチームはまだ、システム開発方法論の認知の単一の統合運用と保守に残っていると思うべきではありませんので、単一のシステムOPS」の上にありますOPS」、DevOpsチームのプラットフォームのように本質的に我々と他のいわゆるグループは、自然の中で非常に大きな違いがあります。

グループより代表DevOpsチームスペースベースのプラットフォームは、メインソリューションをアップグレード、ユーザー指向の性質や運用・保守要員の全体のプロセスに、サービスのソースコード管理とを展開することであるということなプラットフォームです。だから、これに基づいて、IAC（コード、コードなどのインフラストラクチャなどのインフラストラクチャ）寸法+ Gitの配備構成管理製品とグレイグ日はすでに一般的なDevOpsチームのプラットフォームのデザインのアイデアでビルドには十分であるが、唯一のそのような設計実際には、私たちのために、そうでないかもしれない十分な私たちのために、私たちの顧客はオンラインシステムの運用・保守の専門知識を持たないエンドユーザー、あるため、唯一の構成やコードを参照するには、彼はユンカイます。

だから、基本的に、我々はさらに前進のための製品プラットフォームの観点に向かって、理解DevOpsチームに一歩を移動し続ける必要があります話す：まず、フィールドの複雑さの盾ユーザーコードや構成や知識を、第二は、システムのコラボレーションを変更することです唯一それが複雑と終了経験管理とコントロールリンクに全体の終わりを簡素化しなかったので、最後の経験に制御終わりに、本当に私たちは2年を経てきた上記の目標を達成するために、反復の本質的効率改善の複雑な検索操作を行うことができます取り組みが徐々にsophon、バハムート、MAATや他のシステムを上陸させ、また、良好なビジネス反復効率を作りました。

しかし、唯一のアリ・プラットフォームが、まだ完璧で、このような体格のためのDevOpsチームのでしょうか？明らかに、DevOpsチームフルリンクは、R＆D、PEの問題への唯一の効果的なソリューションであり、効率とユーザーエクスペリエンスを持つユーザーが、プラットフォーム側のための事業規模の急速な拡大だけでなく、検索サービスの複雑で多様なタイプと変更に関係していませんビジネスプラットフォームとの矛盾は、実際に転送の自然の中で開催されました：になってきた優れたセキュリティと安定性、合理的なリソース使用率、および大規模の下、各事業の反復の高効率を提供するために、どのように私たちの新しいターゲットプラットフォーム。

現在、我々はホークアイでデータ操作の三年間に基づいてAIOPSの練習に上陸 - オンラインサービスの最適化プラットフォーム、Torch-キャパシティ管理プラットフォームは、Heracles-は、毎日のプレスサービスプラットフォーム、CostMan-コストのサービスシステムを測定しました。これらのサービスのヘルプデスクシステムは、キャパシティ管理、定期点検、キー診断最適化に関するいくつかの初期の結果を達成している、さらに拡張することができます10000 +プラットフォームでのビジネスの数よりも、将来の統一グループ検索操作および保守管理についてもお聞かせスムーズにそれに対処し、確固たる信頼を確立します。

操作の3年間の実績のあるデータが、しかし、複雑な意思決定のパフォーマンスのボトルネック分析、問題の診断、自己修復、運用・保守当社従来は主に降水量の専門知識にとどまるので、我々は、実際のAIOpsから離れてい白の人々やシステムへの降水の経験はオンライン操作やメンテナンスの問題を解決すること、およびAIOPSを楽しみにすることは、当社のAIOpsのヘルプに使用するデータとアルゴリズムの能力私たちは、自動的に問題の法則を発見し、問題を解決するために、このような観点であります我々は、効率、品質保証を強化するために、将来的に願っていますので、プラットフォームはまだ良い未来の発展に対応するために、コストの最適化は本当に助けAIの能力は、プラットフォームを支援することができ、多くの可能性をタップする必要があります。

統合運用・保守慣行を開発するために台湾を検索-Sophon

統合開発運用・保守-DevOPS

我々はシステムの統合-sophon運用・保守の開発を紹介する前に、我々はそれが少し複雑な検索サービスへのアクセスのシーンにし、それらがどのように作業を調整来たときにシステムを見てする必要があります。

チャートから、我々は実際には全体のシステムモジュールは、大きく3つのモジュール、OPS、オンライン、オフラインに分かれていることがわかります。ここで、図オプスに示すような層は明らかにステートフルなサービスをオンラインOPS、オンラインとオフラインのステートレスサービスオプスオプスを分割しました。

つまり、各サービスを個別にOPSは制御を分離し、実際には、複雑なビジネス上に示したようにtisplusがない行に、我々は複雑なビジネスへのアクセス権を持っているときに私の記憶では、結果と組み合わせたマルチサービスシステムである前までですまず最初に、このラインアイテム、ラインの変更や、オンライン上で協力を促進するためにどのように手配し、交換が開くかどうか、オンラインステートレスサービスチーム、オフラインDUMPチーム、ビジネス面、PE、オンラインステートフルなサービスチームを招集することです問題は、お互いに叫んだのグループによってサポートされています：「あなたは私がしたい、長く待つの下で動作する再発行」「あなたは次のステップを行うことができますが、私はこのステップを行っている」とだから、このようなアクセスを、私たちは、私はちょうど私たちは、以前の10ヶ月の事業は、バーの限界の原因となっていたサポート理由を知っても説明してきたものから、信じてどのように低共同効率的な運用た想像してみてください。

これらの痛みのポイントを使用すると、ニーズは、その後、振り返ると、我々は練習DevOpsチームの過程で私たちは、複雑な検索システムを持っている必要があります構築することを考えていると言います：

エンドOPSを提供するために、完全なリンクを体験することは、我々はDevOpsチームたちのシーンの標準的な定義を満たすために考慮したものです。
ターゲット・ドリブンに基づく運用・保守管理にアップグレードする認知必要性の知識に基づいて、運用・保守制御リンクの複雑な手続き方法の運用および保守。
抽象的抽象製品のより良い運用・保守、より良いユーザーを有効にします。
業務効率を向上させる反復は、ビジネスの安定性が基づいて保護することでなければなりません。

これらの要件の痛みのポイントを、我々はこの分野で-Sophonレイアウト技術プラットフォームを持つことになり、その後、我々は、システムの下でのセクションの詳細に分割されます。

検索台湾は練習をDevOpsチーム-Sophon

目標駆動運用・保守

ターゲット主導の操作やメンテナンスの基本は何ですか？実際には、一見、それは我々が我々が目標ベースの運用・保守管理を促進すべきである理由を理解することは、おそらく簡単に説明するために、実際の検索操作やメンテナンスのシナリオを与え、実際には、私の説明を聞いている場合、あなたはそれが非常にシンプルでしょう、あまりにも抽象感じるだろう。

比如我们的搜索系统现在的索引版本是A版本，然后要求系统执行切换索引B版本，但正在rollingB版本的时候，我后悔了我要rolling C 版本。这其实在早些年的时候，线上这种状况是非常让人崩溃的，如果这事让PE去做的话 , 只能杀掉切换流程，检查系统每个节点到哪一步了，清理中间状态，重新发起运维流程，可以想象过程式的运维管控方式在复杂运维体系下是多么低效的事情。

但如果是基于目标驱动的调度，我们只需要重新给系统设定新的rolling C版本，那么系统将会获得最新目标和当前执行渐进的目标进行对比，发现目标状态存在变化，系统会马上终止掉当前执行路径和自动清理系统存在的不一致状态，开始下放最新目标状态关键路径执行通知，各个节点接受到最新命令后开始逐步向新的目标渐进，所以只看最终状态的渐进式最终一致性运维方式自然而然屏蔽了运维中间状态的复杂性，让复杂运维管控变得更加简单更灵活，这也是为什么我们平台自上而下所有的运维方式都升级成了基于目标驱动的原因。

运维概念简化

我们平台一直提到从托管到赋能，言下之意是希望让最终用户承担起自己应当要承担的责任才能享受更强大的搜索能力。但谈到要赋能，那也不能将搜索系统复杂的领域知识和运维概念直接暴露给最终用户，否则这肯定不叫赋能用户，而是叫做折腾用户了。所以如何将系统的运维概念简化，将复杂和潜在领域知识留给系统内部就是sophon需要解决的核心问题之一。

上图下方是从PE视角看到的各个数据中心的基础设施和各种在线服务，如果没有一层管控抽象，让最终用户和PE看到的是一样的复杂度，我相信用户一定会晕菜。

所以sophon做的一个事情就是将运维管控对象抽象成一组数据关系模型，也就是运维管控模型，如上图右侧所示，但是这一层运维抽象依然足够复杂，用户不应该也不需要去了解这层运维抽象，我们应该给用户看到的是触达业务场景的业务抽象，所以sophon在第一层运维抽象之上又抽象了业务抽象，如左上角的三层概念：业务逻辑（插件、配置）、服务（部署关系）、数据（数据源&离线数据处理）。这层的定义用户是几乎无成本就能接受的，所以通过sophon做到的抽象运维概念和简化业务概念的能力也让我们平台从托管到赋能用户成为了可能。

稳定性保障

sophon保障服务稳定性主要体现在2个方面：

当平台支持越来越多的头部核心业务，我们需要对业务的搜索服务进行SLA保障，同时也能适应各个业务根据自己的稳定性要求进行灵活的在离线服务的部署，同时还需要具备自动容灾切换能力。目前sophon服务稳定性方面能够支持搜索在线服务单元化、在离线服务单元化、离线数据冷备部署以及查询链路和数据回流链路自动容灾切切换的能力，如下图所示：

我们前面提到迭代效率提升有一点就是让原先基于时间窗口的线上发布迭代变成了可以24小时随时随地可以发布，但我们说的随时随地并不是代表我们只是提供了发布按钮功能，而不去考虑快速发布过程可能带来的潜在危险，所以高效且安全的发布迭代才是我们追求的目标，这个背后非常重要的基础就是我们设计和标准化了一套发布迭代规范。

例如一次正常的业务迭代，需要经过日常、预发2套环境进行验证，同时在预发发布线上的发布流程中我们加入了多重校验机制来进行发布的稳定性，比如插件、算法策略升级时，我们会要求clone压测对比，如果性能差距太大，发布流程会被回退，同时基于单机房切流灰度发布和冒烟验证等能力可以在发布流程里被定义，所以有了sophon提供的强大的多重校验机制和快速容灾切换的能力，让业务快速迭代中再也没有了后顾之忧，可以将业务运营迭代效率提升到极致，如下图所示：

专家经验沉淀

搜索技术体系虽然功能强大，但强大的背后也有很多专业潜规则，所以如果平台把复杂的运维管控和业务迭代需要遵循的专业知识暴露给普通用户，用户肯定歇菜，所以我们在devops这层一定要将引擎服务领域知识下沉让平台去屏蔽这些复杂性。

举个真实的搜索场景来说，如果业务方有一个字段的修改，但真实情况下一个字段的修改其实是可能涉及到在线和离线的配置联动修改，换句话说你不能说让用户在修改配置的时候让他判断我这次修改是只会影响到在线服务、还是影响到离线服务，还是在离线服务都会影响到，此外配置推送需要先离线服务生效还是在线服务先生效，还是说配置必须做全量后一起生效等等，这些都是引擎服务的专家知识。

目前我们依靠sophon devOPS这层将这些领域知识都在背后默默消费掉了，用户完全不需要关注这些潜在知识，运维平台内部会分解复杂运维操作，然后会根据我们定义好的专家运维DAG图来有条不紊分阶段的进行运维执行，如下图所示：

通过我们不断将运维专家经验沉淀到系统（运维DAG执行流程图），用户对平台的使用成本会不断变小，同时迭代效率也会越来越高。当然如果运维操作变得越来越复杂（比如我们暴露给用户的业务视角需要涵盖越来越多的服务），运维DAG执行链从简单就会发展到可能存在多种执行分支，那么如何在运维执行中寻找到最优执行链路就会成为一个有趣的话题（如上图右边所示），目前我们称之为最短路径选择，这是智能化运维一个有趣的尝试，这也是未来我们持续努力的方向。

从系统到全链路

前面其实也介绍了我们的所有业务场景都是一个技术体系协同的结果，而这个过程中最重要也最具挑战的点便是如何将在线和离线高效协同提供给用户端对端的体验。

从上图可以看到最终用户使用离线数据永远看到的是可视化数据关系定义和简单的dump->Build->switchindex任务执行列表。但是实际上是我们把所有的复杂度屏蔽掉，系统背后却是有一个复杂的状态机在管控在离线的协同，这张图不打算展开讲，整个在离线协同，状态机不是关键，关键是我们如何将每个在线搜索业务对离线数据处理的个性化需求转换成一种抽象，最后通过平台方式来支撑的。

在展开介绍离线平台技术前，稍微跟大家介绍下一个搜索业务对离线处理的普世需求，而这些需求也是没有离线平台之前支持复杂业务在离线跨团队合作中被重复讨论过多次的话题。那就是到引擎的业务数据并不是一个简单的数据库表，它可能来源于多个同构或者异构数据源，同时每个搜索业务都有全量和增量的需求，所以如何将这些根据业务不同而不同数据源关系处理变成一种高层抽象并且屏蔽内部处理环节和统一增量和全量处理流程就变得非常重要，否则来一个业务我们都要为其实现全量和增量数据处理代码简直是不可忍的事情。

现在来回顾之前我们离线支持效率低的原因还是我们之前对引擎schema定义的数据源都是被弱化成一对对的资源进行抽象和管理，也就导致我们没有把本应该的基础的抽象给提炼出来，其实仔细想下来我们目前接入的所有数据资源都是Dynamic Table，所以如果我们以表的抽象去定义这些资源，那一些通用的类似创建表、删除表、修改表、增删改查表数据，定义表之间关系等API都应该可以被收敛掉而不会存在重复开发问题，所以有了这样一个思考，也就有了我们打造离线组件平台-bahamut的整体设计思路。

平台支持用户在平台画布上定义好各自数据源信息和表之间关系定义后（我们可以支持异构表之间的join，例如odps和mysql），我们会将这个前端的Graph提交给Bahamut进行翻译，bahamut将这个前端的Graph解析、优化、拆分、翻译成成若干个blink可执行的graph，比如增量的syncBlink 、全量的BulkLoad MR任务，和Blink Join 任务等。

这里最重要的两个关键的graph节点是merge和left join。merge是将所有的1：1和1：N关系表的处理通过行转列到一个HBASE中间表，而N：1的关系处理以下图的例子来说，我们目前只支持主表N这边（商品表）驱动，也就是说N这方的通过blink sync更新后利用blink Join合并1这方（即用户表）成完整的行记录发送到SwiftSink（增量）&HDFSSink（全量）最终回流到到BuildService构建索引，如下图所示：

通过在线离线管控协同和BaHamut组件平台的打造，可以让用户通过可视化的手段就能享受到强大的离线复杂数据关系处理和计算能力，极大地提升了业务支持效率，同时也让我们平台成为第一个可以整合离线提供在离线端对端体验的里程碑式的产品。另外我们还在做一件事情将离线能力变成在线服务通用能力，相信不远的将来离线组件平台不会是HA3搜索场景的离线组件平台，而是整个搜索在线服务的离线组件平台。

アリは、統合運用・保守慣行を開発するために台湾を検索します