Kiến trúc có thể dạy chúng ta điều gì về các hệ thống tự phục hồi

Được xuất bản lại bởi Plato

Người theo dõi: 0

Các nhóm DevOps và kỹ sư độ tin cậy của trang web (SRE) xử lý mã hàng ngày. Làm như vậy dạy họ xem xét kỹ lưỡng thế giới của họ, đưa ra những quan sát sắc sảo và rút ra những kết nối bất ngờ. Xét cho cùng, mặc dù có bản chất logic và toán học cao, nhưng phát triển phần mềm, ít nhất là một phần, là hình thức nghệ thuật.

Không bị thuyết phục bởi tuyên bố đó? Hãy xem xét sự tương đồng giữa kỳ công kiến trúc đáng chú ý nhất trong lịch sử và công nghệ phần mềm hiện đại. Đó là một so sánh thích hợp: Cũng giống như công nghệ phần mềm, kiến trúc sử dụng các phép tính toán học phức tạp để tạo ra thứ gì đó đẹp đẽ. Và trong cả hai lĩnh vực, một tính toán sai lầm nhỏ có thể dẫn đến hậu quả nghiêm trọng. Thật thú vị, nhiều lỗi kiến trúc nổi tiếng tương tự như các vấn đề chúng ta tìm thấy trong mã.

Hãy nhớ rằng, nguồn cảm hứng ở khắp mọi nơi – miễn là bạn biết tìm ở đâu. Dưới đây là một vài bài học mà các kỹ sư phần mềm có thể học được từ những điều hiển nhiên về kiến trúc qua nhiều thế kỷ, đặc biệt là về tương lai của các hệ thống tự phục hồi.

Bài 1: Edge case sẽ luôn khai thác lỗ hổng hệ thống

Tháp Citicorp – hiện được gọi là 601 Lexington – hoàn thành xây dựng tại Thành phố New York vào năm 1977, vào thời điểm đó, nó là tòa nhà cao thứ bảy trên thế giới. Thiết kế hiện đại nhất của tòa nhà chọc trời bao gồm ba cây cột cao hơn 100 foot. Đó là một điều kỳ diệu khi hoàn thành. Tuy nhiên, một sinh viên đại học đã sớm phát hiện ra một điều gì đó chói tai: Gió mạnh có thể gây nguy hiểm cho tính toàn vẹn của tòa nhà. Cụ thể, nếu những cơn gió mạnh thổi vào các góc của Tháp Citicorp, thì cấu trúc này có thể bị sụp đổ – theo nghĩa đen. trường hợp cạnh.

Tòa tháp có xác suất 16/XNUMX bị sập mỗi năm. Những tỷ lệ cược này có thể lôi kéo ai đó ngồi vào bàn đánh bạc, nhưng viễn cảnh thật ảm đạm đối với các kiến trúc sư và kỹ sư kết cấu đằng sau Tòa tháp Citicorp. Rất may, các kỹ thuật viên đã có thể gia cố các mối nối bắt vít của tòa nhà. Thảm họa đã tránh được.

Các kỹ sư kết cấu biết rằng Tòa tháp Citicorp cuối cùng sẽ phải đối mặt với một cơn gió đủ mạnh để làm ảnh hưởng đến các vòng bi của nó. Tương tự như vậy, các kỹ sư phần mềm dày dạn kinh nghiệm biết rằng giám sát hiệu suất ứng dụng (APM) và quản lý sự kiện mạnh mẽ là không đủ để bảo vệ hệ thống khỏi các trường hợp cạnh không thể tránh khỏi. Đó là bởi vì các hệ thống tĩnh không có học máy (ML) khả năng không thể xử lý các tình huống mới bất ngờ và không có kế hoạch, chẳng hạn như gió chia cắt. Khi chỉ dựa vào các công cụ giám sát, quản trị viên con người phải giải mã lỗi và báo cáo quy trình quản lý sự cố.

Để giảm thời gian trung bình để khôi phục (MTTR)/thời gian trung bình để phát hiện (MTTD), các nhóm DevOps phải chấp nhận xác suất cao của các trường hợp cạnh và làm việc để triển khai trước các giải pháp tự học. Bài học này có giá trị lâu dài, vì tầm nhìn xa là rất quan trọng trong kỹ thuật.

Bài học 2: “Chế tạo máy bay khi nó bay” tạo ra một chu trình không bao giờ kết thúc

Sự kiện bi thảm đã mang lại một số những bài học quan trọng nhất trong lịch sử hàng không. Khi một chiếc máy bay bị giảm áp suất quá lớn giữa chuyến bay và bị rơi vào năm 1954, các kỹ sư đã xác định chắc chắn rằng các cửa sổ hình vuông dành cho hành khách là một điểm căng thẳng không cần thiết. từ đó trở đi, máy bay được trang bị cửa sổ tròn. Các đám cháy trên tàu đã dẫn đến việc sắp xếp chỗ ngồi mới ưu tiên cho việc sơ tán dễ dàng. Những thay đổi này đã cứu sống vô số người.

Trong nhiều ngành công nghiệp – bao gồm cả ngành hàng không – không có cách nào để kiểm tra căng thẳng một sản phẩm một cách triệt để. Như đã đề cập trước đó, các trường hợp cạnh là không thể tránh khỏi. Điểm rút ra lớn nhất ở đây là các kỹ sư phần mềm phải chú ý đến các lỗ hổng trong hệ thống của họ khi chúng xuất hiện. Từ đó, họ phải giải quyết chúng một cách nhanh chóng. Làm được điều đó đòi hỏi hai điều: (1) xác định và theo dõi các chỉ số hiệu suất chính (KPI) phù hợp và (2) đầu tư thời gian và nguồn lực vào việc cải thiện hệ thống dựa trên các số liệu liên quan.

Nhóm kỹ sư trung bình đầu tư vào 16 đến 40 công cụ giám sát, nhưng họ thường bỏ lỡ dấu hiệu về số liệu thể hiện thành công. Ít hơn 15% nhóm theo dõi MTTD, vì vậy họ bỏ lỡ 66% vòng đời sự cố. Và một phần tư số đội báo cáo thiếu các thỏa thuận cấp độ dịch vụ (SLA) của họ mặc dù đầu tư đáng kể vào theo dõi tính khả dụng. Điều này cho chúng ta biết rằng việc thu thập dữ liệu cần phân tích kỹ lưỡng, có hệ thống để cắt giảm nó– các giải pháp điểm không còn đủ nữa.

Các kỹ sư phần mềm, nhóm DevOps và SRE phải ưu tiên các quy trình và công cụ trích xuất giá trị từ lượng thông tin quá lớn về tính khả dụng. Thay vì chỉ quan sát một lỗi nghiêm trọng, họ phải lấy một trang từ cuốn sách của kỹ sư hàng không và đưa ra các quyết định quan trọng một cách nhanh chóng. Bí quyết để làm được điều đó nằm ở AI.

Bài 3: AI là khối xây dựng cơ bản cho hệ thống tự phục hồi

Một hệ thống hoàn toàn tự động, hoạt động hoàn hảo, tự phục hồi là lý tưởng cho bất kỳ kỹ sư phần mềm nào. Các hệ thống tự vá lỗi rất tốt cho sự hài lòng của khách hàng, vì chúng loại bỏ thời gian ngừng hoạt động tốn kém của người tiêu dùng. Hơn nữa, chúng cực kỳ có lợi cho các chức năng quản lý dịch vụ CNTT (ITSM), vì chúng giảm đáng kể nhu cầu quản lý vé tẻ nhạt. Việc xây dựng một hệ thống như vậy đòi hỏi một số thành phần, nhiều thành phần hiện nằm ngoài tầm với. Nhưng chúng ta đang tiến gần đến thực tế tự chữa lành hơn một số người có thể nhận ra.

Việc thiếu áp dụng rộng rãi AI vẫn là trở ngại lớn nhất mà các hệ thống tự phục hồi phải đối mặt ngày nay. Mặc dù nhiều doanh nghiệp đã áp dụng các công cụ dựa trên AI hoặc ML thô sơ, nhưng tính toàn vẹn của những công cụ này vẫn còn nhiều nghi vấn. Điều đó có nghĩa là, nhiều kỹ sư đối phó với trí tuệ nhân tạo cho hoạt động CNTT (AIOps) các công nghệ tuân theo logic tự động hóa dựa trên quy tắc thay vì các thuật toán AI tự trị. Sự khác biệt có vẻ nhỏ nhặt, nhưng trên thực tế, đó là sự khác biệt giữa số giờ năng suất bị mất và hàng triệu đồng có thể bị mất.

Vấn đề là, các công cụ AIOps dựa trên quy tắc phân tích sự tương tác giữa các giải pháp điểm khác nhau và có khả năng xác định các lỗi dữ liệu phổ biến. Nhưng các hệ thống dựa trên tự động hóa không thể xử lý sự phát triển của các lỗi hoàn toàn mới theo thời gian, cũng như không thể dự đoán các trục trặc mới trong dữ liệu. Đó là bởi vì các quản trị viên con người viết mã các chức năng này yêu cầu hệ thống tuân theo một nếu điều này thì đó khuôn mẫu logic. Các công cụ AIOps thực sự hiệu quả giúp giảm thiểu các lỗi phát sinh ở cả bốn điểm đo từ xa cổ điển – từ phát hiện đến giải quyết – bằng cách phân loại các mẫu mới và có vấn đề trước cả khi các kỹ thuật viên là con người nhận thức được sự tồn tại của chúng.

Trong khi chúng tôi chờ đợi làn sóng AI thứ ba sắp xảy ra, phiên bản AIOps này là phiên bản gần nhất với các hệ thống tự phục hồi mà chúng tôi có. Sẽ rất thú vị khi theo dõi cách các ứng dụng AIOps hiện tại chảy vào tương lai của AI, bao gồm khả năng tự động hóa hoàn toàn và khả năng suy nghĩ độc lập. Có thể sau đó các kỹ sư kết cấu cũng sẽ gặt hái được thành quả từ một hệ thống tự phục hồi dựa trên AI.