6重點助你開發自動化維運架構

導讀	維運自動化是我們所渴望獲得的，但是我們在一味強調自動化能力時，卻忽略了影響自動化落地的關鍵因素。那便是跟運維朝夕相處，讓人又愛又恨的業務架構。

#因為業務架構是決定維運效率和品質的關鍵因素之一，所以我想跟大家一起聊一下怎麼樣的架構設計是對維運友善的。結合這些年在騰訊遇到的業務架構和做維運規劃時對業務非功能規範的思考，我們可以把麵向運維的架構設計分成六大設計要點。

 

要點一：架構獨立

任何架構的產生都是為了滿足特定的業務訴求，如果我們在滿足業務要求的同時，能夠兼顧維運對架構管理的非功能性要求。那我們有理由認為這樣的架構是對運維友善的。

#站在運維的角度，所訴求的架構獨立包含四個面向：獨立部署，獨立測試，元件化和技術解耦# 。

獨立部署

#指的是一份原始程式碼，可以依照方便運維的管理要求去部署、升級、伸縮等，可透過設定來區分地理分佈。服務間相互呼叫透過介面請求實現，部署獨立性也是運維獨立性的前提。

獨立測試

#維運能夠通過一些便捷的測試案例或工具，驗證該業務架構或服務的可用性。具備此能力的業務架構或服務讓維運具備了獨立上線的能力，而不需要每次發布或變更都需要開發或測試人員的參與。

元件規格

#指的是在同一個公司內對相關的技術能有很好的框架支持，從而避免不同的開發團隊使用不同的技術堆疊或組件，造成公司內部的技術架構失控。

這種做法能夠限制維運對象的無序增加，讓維運對生產環境始終保持掌控。同時也能夠讓維運保持更多的精力投入，來圍繞著標準組件做更多的效率與品質的建設工作。

技術解耦

#指的是降低服務和服務之間相互依賴的關係，也包含了降低程式碼對設定檔的依賴。這也是實現微服務的基礎，實現獨立部署、獨立測試、元件化的基礎。

要點二：部署友善

DevOps 中有大量的篇幅講述持續交付的技術實踐，希望從端到端打通開發、測試、運維的所有技術環節，以實現快速部署和交付價值的目標。可見，部署是維運日常工作很重要的組成部分，是屬於計畫內的工作，重複度高，必須提升效率。

#實現高效可靠的部署能力，要做好全域規劃，以確保部署以及營運階段的全方位運維掌控。有五個緯度的內容是與部署友善相關的：

CMDB設定

#在每次部署作業前，維運需要清晰的掌握應用與架構、與業務的關係，為了更好的全局理解和評估工作量和潛在風險。

在織雲自動化維運平台中，我們習慣將業務關係、叢集管理、營運狀態、重要層級、架構層等設定資訊作為運維的管理物件納管於CMDB配置管理資料庫中。這種管理辦法的好處很明顯，集中儲存維運對象的配置信息，對日後涉及的運維操作、監控和告警等自動化能力建設，將提供大量的配置數據支撐和決策輔助的功效。

環境配置

#在維運標準化程度不高的企業中，阻礙部署交付效率的原罪之一便是環境配置，這也是容器化技術主要希望解決的維運痛點之一。

騰訊的維運實踐中，對開發、測試、生產三大主要環境的標準化管理，透過枚舉納管與環境相關的資源集合與運維操作，結合自動初始化工具以實現標準環境管理的落地。

依賴管理

#解決應用軟體對庫、營運環境等依賴關係的管理。在織雲實務經驗中，我們利用套件管理，將依賴的庫檔案或環境的配置，透過整體打包和前後置執行腳本的方案，解決應用軟體在不同環境部署的難題。業界還有更輕量的容器化交付方法，也是不錯的選擇。

部署方式

#持續交付原則提到要打造可靠可重複的交付管線，對應用軟體的部署操作，我們也強烈地按此目標來規劃。業界有許多案例可以參考，例如Docker的Build、Ship、Run，如織雲的透過配置描述、標準化流程的一鍵部署等等。

發布自測

#發布自測包含兩部​​分：

1. 應用的輕量級測試；
2. 發布/變更內容的校對。

建立這兩種能力以因應不同的維運場景需求，如在增量發佈時，使用發佈內容的校對能力，維運人員可快速的獲取變更文件md5，或對相關的進程和端口的配置資訊進行檢查比對，確保每次發布變更的可靠。

同理，輕量級測試則是滿足發佈時對服務可用性檢測的需求，此步驟可以檢測服務的連通性，也可以跑些主幹的測試案例。

灰階上線

在《日常運維三十六計》中有這麼一句話：對不可逆的刪除或修改操作，盡量延遲或慢速執行。這便是灰階的思想，無論是從用戶、時間、伺服器等緯度的灰度上線，都是希望盡量降低上線操作的風險，業務架構支持灰度發布的能力，讓應用部署過程的風險降低，對運維更友善。

要點三：可運維性

維運腦中最理想的微服務架構，首當其衝的肯定是可運維性強的那類。 不具可運維性的應用或架構，對維運團隊帶來的不僅僅是黑鍋，還有對他們職業發展的深深的傷害，因為維護一個沒有可運維性的架構，簡直就是在浪費維運人員的生命。

#可運維性依操作規範和管理規範可以歸納為以下七點：

設定管理

#在微服務架構管理中，我們提議將應用的二進位與組態分開管理，以便於實現獨立部署的目的。

被分離出來的應用程式配置，有三種管理方法：

1. 檔案模式；
2. 配置項模式；
3. 分散式配置中心模式。

限於篇幅不就以上三種方式的優劣展開討論。不同的企業可選用最適用的配置管理辦法，關鍵在於要求各業務使用一致的方案，維便可以有針對性的建設工具和系統來做好配置管理。

版本管理

DevOps持續交付八大原則之一「把所有的東西都納入版本控制」。就維運對象而言，想要管理好它，就必須能夠清晰的描述它。

和原始碼管理的要求類似，維運也需要對日常操作的對象，如套件、配置、腳本等都進行腳本化管理，以備在運維繫統在完成自動化操作時，能夠準確無誤的選取被操作的物件和版本。

標準運算

#維運日常有大量重複度高的工作需要被執行，從精實思想的角度看，這裡存在著極大的浪費：學習成本、無價值操作、重複建造的腳本/工具、人肉執行的風險等等。

倘若能在企業內形成統一的運維操作規範，如文件傳輸、遠端執行、應用啟動停止等等操作都被規範化、集中化、一鍵化的操作，維的效率和品質將得以極大的提升。

行程管理

#包括套用安裝路徑、目錄結構、規範進程名、規範連接埠號碼、啟動停止方式、監控方案等等，被收納在進程管理的範疇。 做好進程管理的全域規劃，能夠極大的提升自動化維運程度，減少計畫外任務的發生。

空間管理

#做好磁碟空間使用的管理，是為了確保業務資料的有序存放，也是降低計劃外任務發生的有效手段。

要求提前做好的規劃：備份策略、儲存方案、容量預警、清理策略等，輔以行之有效的工具，讓這些任務不再困擾維運。

日誌管理

#日誌規範的推行和貫徹需要研發密切配合，在實務上得出的經驗，維運理想中的日誌規格要包含這些要求：

• 業務資料與日誌分離
• 日誌與業務邏輯解耦
• 日誌格式統一
• 回傳碼及註解清晰
• 可取得業務指標（請求量/成功率/延遲）
• 定義關鍵事件
• 輸出等級
• 管理方案（存放時長、壓縮備份等）

當具體上述條件的日誌規格得以落地，開發、維運和業務都能相應的獲得較好的監控分析能力。

集中管控

#維運的工作先天就容易被切割成不同的部分，發布變更、監控分析、故障處理、專案支援、多雲管理等等，我們訴求一站式的維運管理平台，使得所有的工作資訊能夠銜接起來與傳承經驗，杜絕因為資訊孤島或人工傳遞訊息而造成的營運風險，提升整體維運管控的效率與品質。

要點四：容錯容災

在騰訊技術運作（維運）的四大職責：品質、效率、成本、安全。品質是首要保障的陣地，轉換成架構的視角，維運眼中理想的高可用架構架構設計應該包含以下幾點：

# 負載平衡

#無論是軟體或硬體的負責均衡的方案，從運維的角度出發，我們總希望業務架構是無狀態的，路由尋址是智慧化的，叢集容錯是自動實現的。

在騰訊多年的路由軟體實務中，軟體的負載平衡方案被廣泛應用，為業務架構實現高可用立下汗馬功勞。

可調度性

#在行動互聯網盛行的年代，可調度性是容災容錯的極為重要的維運手段。在業務遭遇無法立刻解決的故障時，將使用者或服務調離異常區域，是海量營運實務中屢試不爽的技巧，也是騰訊QQ和微信保障平台業務品質的核心維運能力之一。

結合網域名稱、VIP、接取網關等技術，讓架構支援調度的能力，豐富維運管理手段，有能力更從容的應對各種故障場景。

Live more in a different place

Multi-activity in remote locations is a requirement for high data availability and a prerequisite for schedulability. For different business scenarios, there are no limitations on the means of technical implementation.

For the practice of Tencent social networking, you can refer to teacher Zhou Xiaojun’s article “Architectural design and efficient operation behind the large-scale scheduling of 200 million QQ users”.

Master-slave switching

In the high-availability solution of the database, master-slave switching is the most common disaster recovery and fault tolerance solution. By realizing the separation of reading and writing in business logic, and combining it with intelligent routing to realize unmanned master-slave switching automation, it is undoubtedly the best gift of architectural design to DBA.

Flexible and available

"Sure first and then optimize" is one of Tencent's massive operational ideas, and it also points the way for us to do high-availability design of business architecture.

How to ensure service availability to the greatest extent when business volume suddenly increases? This is an unavoidable issue when doing architectural planning and design. Cleverly setting flexible switches, or building logic to automatically reject excessive requests in the architecture, can ensure that back-end services do not collapse at critical moments and ensure the high availability of the business architecture.

Point 5: Quality Control

Ensuring and improving business quality is the goal that operation and maintenance strives to pursue, and monitoring capabilities are an important technical means for us to achieve our goals. Operation and maintenance hopes that the architecture will provide convenience and data support for quality monitoring, and requires the following points to be achieved:

Indicators

Every architecture must be measured by indicators. At the same time, what we hope is that it is best to have only one indicator measurement. As business becomes more and more sophisticated in three-dimensional monitoring, the number of monitoring indicators will increase exponentially. Therefore, for the metric measurement of the architecture, what we hope is that it is best to have only a unique metric measurement.

Basic monitoring

refers to low-level indicator capabilities such as networks, dedicated lines, hosts, and systems. Most of these monitoring points are non-intrusive and can easily collect data.

In enterprises with sound automated operation and maintenance capabilities, most of the alarm data generated by basic monitoring will be converged. At the same time, this part of monitoring data will provide data support and decision-making basis for high-level business monitoring, or be packaged into business monitoring data that is closer to upper-level application scenarios, such as capacity, multi-dimensional indicators, etc.

Component monitoring

Tencent is accustomed to collectively refer to development frameworks, routing services, middleware, etc. as components. This type of monitoring is between basic monitoring and business monitoring. Operations and maintenance often rely on embedding monitoring logic in components. Through the components of Promotion will increase the coverage of component monitoring, and the cost of obtaining data will be moderate. For example, by using the monitoring of routing components, operation and maintenance can obtain status and quality indicators such as request volume and delay of each routing service.

Business Monitoring

The implementation methods of business monitoring are divided into active and passive monitoring, which can be implemented intrusively or by bypass. This type of monitoring solution requires development cooperation, both in terms of coding and architecture.

Usually, business monitoring indicators can be summarized into three indicators: request volume, success rate, and delay. There are many implementation methods, including log monitoring, flow data monitoring, wave testing, etc. Business monitoring is a high-level monitoring and can often directly feedback business problems. However, if you want to deeply analyze the root cause of the problem, it must be combined with necessary operation and maintenance monitoring. Management specifications, such as return code definitions, logging protocols, etc. When designing the business architecture, the requirements of operation and maintenance monitoring and management must be considered in advance, and the scope of the overall planning needs to be well planned.

Полный мониторинг ссылок

Методы мониторинга основы, компонентов и бизнеса больше ориентированы на точечный мониторинг.В бизнес-сценарии распределенной архитектуры для хорошего мониторинга мы должны учитывать мониторинг ссылок на запросы на обслуживание.

На основе уникального идентификатора транзакции или отношения вызовов RPC технические средства используются для восстановления цепочки отношений вызовов, а затем с помощью моделей или событий запускаются сигналы мониторинга для обратной связи о состоянии и качестве канала обслуживания. Этот метод мониторинга представляет собой высококлассное приложение мониторинга, которое также требует предварительного планирования и скрытого кода при планировании бизнес-архитектуры. .

Оценка качества

Любое продвижение возможностей мониторинга и оптимизация качества требуют замкнутого цикла управления. Оценка является хорошим средством. От охвата мониторинга, полноты показателей, механизмов управления событиями до оценки и оценки отчетов, эксплуатация, обслуживание и развитие могут работать рука об руку. Создайте замкнутый цикл управления качеством с постоянной обратной связью, чтобы бизнес-структура могла продолжать развиваться и совершенствоваться.

Пункт 6: Стоимость производительности

В Tencent весь технический персонал выполняет важную функцию, которая заключается в обеспечении разумности операционных расходов бизнеса. Для этого мы должны иметь соответствующие методы управления производительностью приложений, планированием мощности бизнеса и эксплуатационными расходами.

Производительность

В методологии непрерывной доставки DevOps одним из наиболее важных аспектов тестирования нефункциональных требований на этапе тестирования является стресс-тест производительности пропускной способности архитектуры, чтобы гарантировать работоспособность бизнес-мощностей после запуска приложения. запущен.

В практике Tencent мы не только проводим стресс-тестирование производительности на этапе тестирования, но также объединяем функции компонентов маршрутизации для проведения стресс-тестирования реальных запросов на бизнес-модулях и бизнес-наборах, чтобы установить базовый уровень для модели бизнес-мощности. Он также предоставляет данные со стороны, чтобы продемонстрировать, соответствует ли пропускная способность бизнес-архитектуры требованиям оценки затрат, и использует сравнение данных о производительности между различными предприятиями для содействия постоянному улучшению производительности архитектуры.

Планирование мощности

Слово емкость на английском языке можно перевести как: производительность приложений, мощность обслуживания и общий объем бизнес-запросов. Планирование мощности для эксплуатации и обслуживания относится к разумному планированию мощности обслуживания на основе общего объема бизнес-запросов при предположении, что производительность приложения достигает стандарт.

Операционные затраты

Сокращение эксплуатационных расходов означает сокращение денежных потоков для компании, а его ценность для предприятия не меньшая, чем повышение качества и эффективности.

Tencent фокусируется на мультимедийном бизнесе, таком как социальные сети, пользовательский контент, облачные вычисления, игры и видео, и ежегодно потребляет огромные операционные расходы, такие как пропускная способность и оборудование. Если эксплуатация и техническое обслуживание хотят оптимизировать эксплуатационные расходы, это часто включает в себя оптимизацию функций продукта и бизнес-архитектуры. Таким образом, идеальная бизнес-архитектура для эксплуатации и обслуживания требует достаточной осведомленности о затратах,

краткое содержание

Эта статья основана исключительно на некоторых личных мнениях о проектировании микросервисной архитектуры с точки зрения эксплуатации и обслуживания. Бизнес-архитектура не должна быть неразжевываемой.

Люди, занимающиеся эксплуатацией и обслуживанием, должны обладать знаниями в области архитектуры и иметь возможность вносить предложения или требования к бизнес-архитектуре с разных точек зрения. Это также поддерживается духом DevOps. Разработка, эксплуатация и обслуживание работают вместе для постоянной оптимизации лучшей бизнес-архитектуры. .

以上是6重點助你開發自動化維運架構的詳細內容。更多資訊請關注PHP中文網其他相關文章！