Ngày nay, dịch vụ Bitrix24 không có lưu lượng truy cập hàng trăm gigabit cũng như không có đội máy chủ khổng lồ (mặc dù tất nhiên có khá nhiều máy chủ hiện có). Nhưng đối với nhiều khách hàng, nó là công cụ chính để làm việc trong công ty; nó là một ứng dụng thực sự quan trọng trong kinh doanh. Vì vậy, không có cách nào để rơi. Điều gì sẽ xảy ra nếu sự cố xảy ra nhưng dịch vụ lại “khôi phục” nhanh đến mức không ai nhận ra điều gì? Và làm thế nào có thể thực hiện chuyển đổi dự phòng mà không làm giảm chất lượng công việc và số lượng khách hàng? Alexander Demidov, giám đốc dịch vụ đám mây tại Bitrix24, đã phát biểu trên blog của chúng tôi về hệ thống đặt chỗ đã phát triển như thế nào sau 7 năm tồn tại của sản phẩm.
“Chúng tôi đã ra mắt Bitrix24 dưới dạng SaaS cách đây 7 năm. Khó khăn chính có lẽ là như sau: trước khi được ra mắt công khai dưới dạng SaaS, sản phẩm này chỉ tồn tại ở dạng giải pháp đóng hộp. Khách hàng đã mua nó từ chúng tôi, lưu trữ nó trên máy chủ của họ, thiết lập cổng thông tin công ty - một giải pháp chung để liên lạc với nhân viên, lưu trữ tệp, quản lý tác vụ, CRM, chỉ vậy thôi. Và đến năm 2012, chúng tôi quyết định muốn khởi chạy nó dưới dạng SaaS, tự quản lý nó, đảm bảo khả năng chịu lỗi và độ tin cậy. Chúng tôi đã tích lũy được kinh nghiệm trong suốt chặng đường, bởi vì cho đến lúc đó chúng tôi đơn giản là chưa có - chúng tôi chỉ là nhà sản xuất phần mềm chứ không phải nhà cung cấp dịch vụ.
Khi ra mắt dịch vụ, chúng tôi hiểu rằng điều quan trọng nhất là đảm bảo khả năng chịu lỗi, độ tin cậy và tính sẵn sàng liên tục của dịch vụ, bởi vì nếu bạn có một trang web thông thường đơn giản, chẳng hạn như một cửa hàng, và nó sẽ rơi vào bạn và nằm ở đó trong một giờ, chỉ có bạn đau khổ, bạn mất đơn hàng, bạn mất khách hàng, nhưng đối với chính khách hàng của bạn, điều này không quá quan trọng đối với anh ta. Tất nhiên là anh ấy rất buồn nhưng anh ấy đã đi mua nó trên một trang web khác. Và nếu đây là một ứng dụng gắn liền với mọi công việc trong công ty, thông tin liên lạc, quyết định, thì điều quan trọng nhất là phải chiếm được lòng tin của người dùng, tức là không để họ thất vọng và không bị gục ngã. Bởi vì mọi công việc có thể dừng lại nếu có thứ gì đó bên trong không hoạt động.
Bitrix.24 dưới dạng SaaS
Chúng tôi đã lắp ráp nguyên mẫu đầu tiên một năm trước khi ra mắt công chúng vào năm 2011. Chúng tôi đã lắp ráp nó trong khoảng một tuần, xem xét, xoay nó - thậm chí nó còn hoạt động. Nghĩa là, bạn có thể vào biểu mẫu, nhập tên của cổng vào đó, một cổng mới sẽ mở ra và cơ sở người dùng sẽ được tạo. Chúng tôi đã xem xét nó, đánh giá sản phẩm về mặt nguyên tắc, loại bỏ nó và tiếp tục tinh chỉnh nó trong cả năm. Bởi vì chúng tôi có một nhiệm vụ lớn: chúng tôi không muốn tạo hai cơ sở mã khác nhau, chúng tôi không muốn hỗ trợ một sản phẩm đóng gói riêng biệt, các giải pháp đám mây riêng biệt - chúng tôi muốn thực hiện tất cả trong một mã.
Một ứng dụng web điển hình vào thời điểm đó là một máy chủ chạy một số mã PHP, cơ sở dữ liệu mysql, các tệp được tải lên, tài liệu, hình ảnh được đưa vào thư mục tải lên - tất cả đều hoạt động. Than ôi, không thể khởi chạy một dịch vụ web cực kỳ ổn định bằng cách sử dụng dịch vụ này. Ở đó, bộ nhớ đệm phân tán không được hỗ trợ, bản sao cơ sở dữ liệu không được hỗ trợ.
Chúng tôi đã đưa ra các yêu cầu: đây là khả năng được đặt ở các vị trí khác nhau, hỗ trợ nhân rộng và lý tưởng nhất là được đặt ở các trung tâm dữ liệu được phân bổ theo địa lý khác nhau. Tách biệt logic sản phẩm và trên thực tế là lưu trữ dữ liệu. Có thể mở rộng quy mô linh hoạt theo tải và chịu đựng hoàn toàn các trạng thái tĩnh. Trên thực tế, từ những cân nhắc này, các yêu cầu đối với sản phẩm đã xuất hiện và chúng tôi đã cải tiến trong suốt năm qua. Trong thời gian này, trên nền tảng hóa ra là hợp nhất - dành cho các giải pháp đóng hộp, cho dịch vụ của chính chúng tôi - chúng tôi đã hỗ trợ những thứ mà chúng tôi cần. Hỗ trợ sao chép mysql ở cấp độ của chính sản phẩm: nghĩa là nhà phát triển viết mã không nghĩ về cách phân phối yêu cầu của mình, anh ta sử dụng api của chúng tôi và chúng tôi biết cách phân phối chính xác các yêu cầu ghi và đọc giữa các bậc thầy và nô lệ.
Chúng tôi đã hỗ trợ ở cấp sản phẩm cho nhiều kho lưu trữ đối tượng đám mây khác nhau: google storage, amazon s3, cùng với hỗ trợ cho open stack swift. Do đó, điều này thuận tiện cho cả chúng tôi với tư cách là một dịch vụ và cho các nhà phát triển làm việc với giải pháp đóng gói: nếu họ chỉ sử dụng API của chúng tôi cho công việc, họ sẽ không nghĩ đến việc tệp cuối cùng sẽ được lưu ở đâu, cục bộ trên hệ thống tệp hoặc trong kho lưu trữ tệp đối tượng.
Do đó, chúng tôi ngay lập tức quyết định rằng chúng tôi sẽ dự trữ ở cấp độ toàn bộ trung tâm dữ liệu. Vào năm 2012, chúng tôi đã ra mắt hoàn toàn trên Amazon AWS vì chúng tôi đã có kinh nghiệm với nền tảng này - trang web riêng của chúng tôi được lưu trữ ở đó. Chúng tôi bị thu hút bởi thực tế là ở mỗi khu vực, Amazon có một số vùng sẵn sàng - trên thực tế, (theo thuật ngữ của họ) một số trung tâm dữ liệu ít nhiều độc lập với nhau và cho phép chúng tôi dự trữ ở cấp độ toàn bộ trung tâm dữ liệu: nếu nó đột ngột bị lỗi, cơ sở dữ liệu sẽ được sao chép master-master, các máy chủ ứng dụng web sẽ được sao lưu và dữ liệu tĩnh sẽ được chuyển sang bộ lưu trữ đối tượng s3. Tải được cân bằng - vào thời điểm đó bởi Amazon elb, nhưng một lát sau, chúng tôi đã sử dụng bộ cân bằng tải của riêng mình vì chúng tôi cần logic phức tạp hơn.
Những gì họ muốn là những gì họ có...
Tất cả những điều cơ bản mà chúng tôi muốn đảm bảo - khả năng chịu lỗi của bản thân máy chủ, ứng dụng web, cơ sở dữ liệu - mọi thứ đều hoạt động tốt. Kịch bản đơn giản nhất: nếu một trong các ứng dụng web của chúng tôi bị lỗi, thì mọi thứ đều đơn giản - chúng sẽ bị tắt khỏi trạng thái cân bằng.
Bộ cân bằng (lúc đó là Elb của Amazon) đã đánh dấu các máy không hoạt động là không tốt và tắt phân phối tải trên chúng. Tính năng tự động chia tỷ lệ của Amazon đã hoạt động: khi tải tăng lên, các máy mới được thêm vào nhóm tự động chia tỷ lệ, tải được phân bổ cho các máy mới - mọi thứ đều ổn. Với bộ cân bằng của chúng tôi, logic gần như giống nhau: nếu có điều gì đó xảy ra với máy chủ ứng dụng, chúng tôi sẽ xóa yêu cầu khỏi máy chủ đó, loại bỏ các máy này, khởi động máy mới và tiếp tục hoạt động. Kế hoạch này đã thay đổi một chút trong những năm qua, nhưng vẫn tiếp tục hoạt động: nó đơn giản, dễ hiểu và không có khó khăn gì với nó.
Chúng tôi làm việc trên toàn thế giới, lượng khách hàng cao nhất là hoàn toàn khác nhau và theo một cách thân thiện, chúng tôi có thể thực hiện một số công việc dịch vụ nhất định trên bất kỳ thành phần nào trong hệ thống của mình bất kỳ lúc nào - không bị khách hàng chú ý. Do đó, chúng tôi có cơ hội ngừng hoạt động cơ sở dữ liệu, phân phối lại tải cho trung tâm dữ liệu thứ hai.
Mọi chuyện diễn ra như thế nào? — Chúng tôi chuyển lưu lượng truy cập sang một trung tâm dữ liệu đang hoạt động - nếu xảy ra tai nạn tại trung tâm dữ liệu thì hoàn toàn, nếu đây là công việc theo kế hoạch của chúng tôi với một cơ sở dữ liệu, thì chúng tôi sẽ chuyển một phần lưu lượng phục vụ các khách hàng này sang trung tâm dữ liệu thứ hai, tạm dừng nó sao chép. Nếu cần máy mới cho các ứng dụng web vì tải trên trung tâm dữ liệu thứ hai đã tăng lên, chúng sẽ tự động khởi động. Chúng tôi hoàn thành công việc, bản sao được khôi phục và chúng tôi trả lại toàn bộ tải. Nếu chúng ta cần phản chiếu một số công việc trong DC thứ hai, chẳng hạn như cài đặt các bản cập nhật hệ thống hoặc thay đổi cài đặt trong cơ sở dữ liệu thứ hai, thì nói chung, chúng ta lặp lại điều tương tự, chỉ theo hướng khác. Và nếu đây là một tai nạn, thì chúng tôi sẽ làm mọi thứ một cách tầm thường: chúng tôi sử dụng cơ chế xử lý sự kiện trong hệ thống giám sát. Nếu một số kiểm tra được kích hoạt và trạng thái chuyển sang mức quan trọng thì chúng tôi sẽ chạy trình xử lý này, một trình xử lý có thể thực thi logic này hoặc logic kia. Đối với mỗi cơ sở dữ liệu, chúng tôi chỉ định máy chủ nào sẽ chuyển đổi dự phòng cho cơ sở dữ liệu đó và nơi lưu lượng truy cập cần được chuyển đổi nếu không có sẵn. Trong lịch sử, chúng tôi sử dụng nagios hoặc một số nhánh của nó ở dạng này hay dạng khác. Về nguyên tắc, các cơ chế tương tự tồn tại trong hầu hết mọi hệ thống giám sát; chúng tôi chưa sử dụng bất cứ thứ gì phức tạp hơn, nhưng có lẽ một ngày nào đó chúng tôi sẽ sử dụng. Hiện tại, việc giám sát được kích hoạt do không có sẵn và có khả năng chuyển đổi thứ gì đó.
Chúng ta đã bảo lưu mọi thứ chưa?
Chúng tôi có nhiều khách hàng từ Mỹ, nhiều khách hàng từ Châu Âu, nhiều khách hàng ở gần phương Đông hơn - Nhật Bản, Singapore, v.v. Tất nhiên, một lượng lớn khách hàng là ở Nga. Đó là, công việc không ở một khu vực. Người dùng muốn phản hồi nhanh, có các yêu cầu phải tuân thủ nhiều luật địa phương khác nhau và trong mỗi khu vực, chúng tôi dành hai trung tâm dữ liệu, ngoài ra còn có một số dịch vụ bổ sung, một lần nữa, thuận tiện để đặt trong một khu vực - dành cho những khách hàng ở khu vực này đang hoạt động. Trình xử lý REST, máy chủ ủy quyền, chúng ít quan trọng hơn đối với hoạt động của toàn bộ máy khách, bạn có thể chuyển đổi qua chúng với độ trễ nhỏ có thể chấp nhận được, nhưng bạn không muốn phát minh lại cách giám sát chúng và những việc cần làm với họ. Do đó, chúng tôi đang cố gắng sử dụng tối đa các giải pháp hiện có thay vì phát triển một số loại năng lực trong các sản phẩm bổ sung. Và ở đâu đó, chúng tôi sử dụng chuyển đổi ở cấp độ DNS một cách tầm thường và chúng tôi xác định mức độ hoạt động của dịch vụ bằng cùng một DNS. Amazon có dịch vụ Route 53, nhưng nó không chỉ là một DNS để bạn có thể tạo các mục nhập và chỉ thế thôi—nó linh hoạt và thuận tiện hơn nhiều. Thông qua đó, bạn có thể xây dựng các dịch vụ được phân phối theo địa lý với vị trí địa lý, khi bạn sử dụng nó để xác định khách hàng đến từ đâu và cung cấp cho anh ta một số hồ sơ nhất định - với sự trợ giúp của nó, bạn có thể xây dựng kiến trúc chuyển đổi dự phòng. Các hoạt động kiểm tra tình trạng tương tự cũng được định cấu hình trong chính Tuyến 53, bạn đặt các điểm cuối được theo dõi, đặt số liệu, đặt giao thức nào để xác định “khả năng hoạt động” của dịch vụ - tcp, http, https; đặt tần suất kiểm tra để xác định xem dịch vụ có hoạt động hay không. Và trong chính DNS, bạn chỉ định cái gì sẽ là chính, cái gì sẽ là phụ, chuyển đổi ở đâu nếu quá trình kiểm tra tình trạng được kích hoạt bên trong tuyến đường 53. Tất cả điều này có thể được thực hiện bằng một số công cụ khác, nhưng tại sao nó lại thuận tiện - chúng tôi đã đặt nó lên một lần và sau đó không nghĩ gì về cách chúng ta kiểm tra, cách chúng ta chuyển đổi: mọi thứ đều tự hoạt động.
Chữ “nhưng” đầu tiên: làm thế nào và bằng những gì để đặt trước tuyến đường 53? Ai biết được, nếu có chuyện gì xảy ra với anh ấy thì sao? May mắn thay, chúng tôi chưa bao giờ giẫm phải cái cào này, nhưng một lần nữa, tôi sẽ có trước một câu chuyện về lý do tại sao chúng tôi nghĩ rằng chúng tôi vẫn cần phải đặt chỗ trước. Ở đây chúng tôi đã bày sẵn ống hút cho mình. Vài lần trong ngày, chúng tôi thực hiện dỡ bỏ hoàn toàn tất cả các khu vực mà chúng tôi có trên tuyến đường 53. API của Amazon cho phép bạn dễ dàng gửi chúng dưới dạng JSON và chúng tôi có một số máy chủ dự phòng nơi chúng tôi chuyển đổi nó, tải nó lên dưới dạng cấu hình và nói một cách đại khái là có cấu hình sao lưu. Nếu có điều gì xảy ra, chúng ta có thể nhanh chóng triển khai thủ công mà không làm mất dữ liệu cài đặt DNS.
Chữ "nhưng" thứ hai: Điều gì trong bức hình này vẫn chưa được đặt trước? Bản thân sự cân bằng! Việc phân bổ khách hàng theo khu vực của chúng tôi được thực hiện rất đơn giản. Chúng tôi có các miền bitrix24.ru, bitrix24.com, .de - hiện có 13 miền khác nhau, hoạt động ở nhiều khu vực khác nhau. Chúng tôi đã đi đến kết luận sau: mỗi khu vực có bộ cân bằng riêng. Điều này giúp việc phân phối giữa các khu vực trở nên thuận tiện hơn, tùy thuộc vào vị trí tải cao nhất trên mạng. Nếu đây là lỗi ở cấp độ của một bộ cân bằng duy nhất, thì nó chỉ cần ngừng hoạt động và bị xóa khỏi dns. Nếu có vấn đề gì đó với một nhóm bộ cân bằng, thì chúng sẽ được sao lưu trên các trang khác và việc chuyển đổi giữa chúng được thực hiện bằng cùng một tuyến đường53, vì do TTL ngắn nên việc chuyển đổi diễn ra trong vòng tối đa 2, 3, 5 phút .
Chữ “nhưng” thứ ba: Cái gì chưa được đặt trước? S3, đúng. Khi chúng tôi đặt các tệp mà chúng tôi lưu trữ cho người dùng vào s3, chúng tôi thực sự tin rằng nó có khả năng xuyên giáp và không cần phải dự trữ bất cứ thứ gì ở đó. Nhưng lịch sử cho thấy mọi chuyện diễn ra khác hẳn. Nhìn chung, Amazon mô tả S3 là một dịch vụ cơ bản, vì bản thân Amazon sử dụng S3 để lưu trữ hình ảnh máy, cấu hình, hình ảnh AMI, ảnh chụp nhanh... Và nếu s3 gặp sự cố, như đã từng xảy ra một lần trong suốt 7 năm qua, chừng nào chúng ta còn sử dụng bitrix24, nó chạy theo nó như một cái quạt. Có rất nhiều thứ sẽ xảy ra – không thể khởi động máy ảo, lỗi api, v.v.
Và S3 có thể rơi - điều đó đã xảy ra một lần. Do đó, chúng tôi đã đi đến kế hoạch sau: vài năm trước ở Nga không có cơ sở lưu trữ đồ vật công cộng nghiêm túc nào và chúng tôi đã cân nhắc lựa chọn làm điều gì đó của riêng mình... May mắn thay, chúng tôi đã không bắt đầu làm điều này, bởi vì chúng tôi sẽ đã đào sâu vào kiến thức chuyên môn mà chúng tôi không có và có thể sẽ gây rối. Hiện Mail.ru có bộ lưu trữ tương thích với s3, Yandex có nó và một số nhà cung cấp khác cũng có nó. Cuối cùng, chúng tôi nảy ra ý tưởng rằng trước hết chúng tôi muốn có bản sao lưu và thứ hai là khả năng làm việc với các bản sao cục bộ. Cụ thể đối với khu vực Nga, chúng tôi sử dụng dịch vụ Hotbox Mail.ru, API tương thích với s3. Chúng tôi không cần bất kỳ sửa đổi lớn nào đối với mã bên trong ứng dụng và chúng tôi đã tạo ra cơ chế sau: trong s3 có các trình kích hoạt kích hoạt việc tạo/xóa đối tượng, Amazon có một dịch vụ tên là Lambda - đây là một chương trình khởi chạy mã không cần máy chủ điều đó sẽ được thực thi ngay khi một số kích hoạt nhất định được kích hoạt.
Chúng tôi đã làm điều đó rất đơn giản: nếu trình kích hoạt của chúng tôi kích hoạt, chúng tôi sẽ thực thi mã sẽ sao chép đối tượng vào bộ lưu trữ Mail.ru. Để bắt đầu hoàn toàn công việc với các bản sao dữ liệu cục bộ, chúng tôi cũng cần đồng bộ hóa ngược để những khách hàng ở phân khúc Nga có thể làm việc với bộ lưu trữ gần họ hơn. Thư sắp hoàn tất quá trình kích hoạt trong bộ lưu trữ của nó - có thể thực hiện đồng bộ hóa ngược ở cấp cơ sở hạ tầng, nhưng hiện tại chúng tôi đang thực hiện việc này ở cấp mã của riêng mình. Nếu chúng tôi thấy rằng khách hàng đã đăng một tệp thì ở cấp độ mã, chúng tôi sẽ đặt sự kiện vào hàng đợi, xử lý nó và thực hiện sao chép ngược lại. Tại sao nó tệ: nếu chúng ta thực hiện một số loại công việc với các đối tượng bên ngoài sản phẩm của mình, tức là bằng một số phương tiện bên ngoài, chúng ta sẽ không tính đến nó. Do đó, chúng tôi đợi cho đến khi kết thúc, khi trình kích hoạt xuất hiện ở cấp độ lưu trữ, để cho dù chúng tôi thực thi mã từ đâu, đối tượng đến với chúng tôi sẽ được sao chép theo hướng khác.
Ở cấp độ mã, chúng tôi đăng ký cả hai kho lưu trữ cho mỗi khách hàng: một kho được coi là kho chính, kho còn lại được coi là kho dự phòng. Nếu mọi thứ đều ổn, chúng tôi làm việc với bộ lưu trữ gần chúng tôi hơn: nghĩa là, khách hàng của chúng tôi ở Amazon, họ làm việc với S3 và những người làm việc ở Nga, họ làm việc với Hotbox. Nếu cờ được kích hoạt thì chuyển đổi dự phòng sẽ được kết nối và chúng tôi sẽ chuyển máy khách sang bộ lưu trữ khác. Chúng ta có thể đánh dấu vào ô này một cách độc lập theo khu vực và có thể chuyển đổi qua lại. Chúng tôi chưa sử dụng điều này trong thực tế, nhưng chúng tôi đã cung cấp cơ chế này và chúng tôi nghĩ rằng một ngày nào đó chúng tôi sẽ cần chính công tắc này và có ích. Điều này đã xảy ra một lần rồi.
Ồ, và Amazon đã bỏ chạy...
Tháng XNUMX này đánh dấu ngày kỷ niệm bắt đầu chặn Telegram ở Nga. Nhà cung cấp bị ảnh hưởng nhiều nhất thuộc trường hợp này là Amazon. Và thật không may, các công ty Nga làm việc cho cả thế giới lại phải chịu đựng nhiều hơn.
Nếu công ty có quy mô toàn cầu và Nga là một phân khúc rất nhỏ đối với công ty đó, 3-5% - tốt, bằng cách này hay cách khác, bạn có thể hy sinh họ.
Nếu đây là một công ty hoàn toàn của Nga - tôi chắc chắn rằng nó cần phải được đặt tại địa phương - thì đơn giản là nó sẽ thuận tiện cho bản thân người dùng, thoải mái và sẽ có ít rủi ro hơn.
Điều gì sẽ xảy ra nếu đây là một công ty hoạt động trên toàn cầu và có số lượng khách hàng xấp xỉ bằng nhau từ Nga và một nơi nào đó trên thế giới? Khả năng kết nối của các phân khúc rất quan trọng và chúng phải phối hợp với nhau theo cách này hay cách khác.
Vào cuối tháng 2018 năm 3, Roskomnadzor đã gửi một lá thư cho các nhà khai thác lớn nhất cho biết họ có kế hoạch chặn hàng triệu IP của Amazon để chặn... trình nhắn tin Zello. Nhờ chính những nhà cung cấp này - họ đã tiết lộ thành công bức thư cho mọi người và người ta hiểu rằng mối liên hệ với Amazon có thể bị đứt đoạn. Đó là thứ Sáu, chúng tôi hoảng sợ chạy đến gặp các đồng nghiệp của mình từ server.ru và nói: “Các bạn ơi, chúng tôi cần một số máy chủ sẽ không được đặt ở Nga, không phải ở Amazon, mà chẳng hạn như ở đâu đó ở Amsterdam,” theo thứ tự để ít nhất bằng cách nào đó có thể cài đặt VPN và proxy của riêng chúng tôi ở đó cho một số điểm cuối mà chúng tôi không thể tác động theo bất kỳ cách nào, chẳng hạn như các điểm cuối của cùng một sXNUMX - chúng tôi không thể cố gắng phát triển một dịch vụ mới và nhận một ip khác, chúng tôi, bạn vẫn cần phải đến đó. Chỉ trong vài ngày, chúng tôi đã thiết lập các máy chủ này, thiết lập và chạy chúng và nói chung là chuẩn bị cho thời điểm bắt đầu chặn. Điều tò mò là RKN, nhìn sự ồn ào và hoảng sợ, nói: “Không, bây giờ chúng tôi sẽ không chặn bất cứ điều gì”. (Nhưng điều này chính xác là cho đến thời điểm Telegram bắt đầu bị chặn.) Sau khi thiết lập các khả năng bỏ qua và nhận ra rằng tính năng chặn chưa được giới thiệu, tuy nhiên, chúng tôi vẫn chưa bắt đầu giải quyết toàn bộ vấn đề. Vâng, chỉ trong trường hợp.
Và vào năm 2019, chúng ta vẫn đang sống trong tình trạng bị phong tỏa. Tôi đã xem tối qua: khoảng một triệu IP tiếp tục bị chặn. Đúng là Amazon gần như đã được bỏ chặn hoàn toàn, lúc cao điểm nó đạt tới 20 triệu địa chỉ... Nói chung, thực tế là có thể không có sự mạch lạc, mạch lạc tốt. Đột nhiên. Nó có thể không tồn tại vì lý do kỹ thuật - hỏa hoạn, máy xúc, tất cả những thứ đó. Hoặc, như chúng ta đã thấy, không hoàn toàn mang tính kỹ thuật. Do đó, một người nào đó lớn và lớn, có AS riêng, có thể quản lý việc này theo những cách khác - kết nối trực tiếp và những thứ khác đã ở cấp độ l2. Nhưng trong phiên bản đơn giản, như phiên bản của chúng tôi hoặc thậm chí nhỏ hơn, đề phòng, bạn có thể dự phòng ở cấp độ máy chủ được nâng lên ở một nơi khác, được định cấu hình trước vpn, proxy, với khả năng nhanh chóng chuyển cấu hình sang chúng trong các phân đoạn đó điều đó rất quan trọng cho khả năng kết nối của bạn. Điều này đã hơn một lần có ích cho chúng tôi, khi việc chặn Amazon bắt đầu; trong trường hợp xấu nhất, chúng tôi chỉ cho phép lưu lượng truy cập S3 đi qua họ, nhưng dần dần tất cả điều này đã được giải quyết.
Làm thế nào để đặt trước... toàn bộ nhà cung cấp?
Hiện tại, chúng tôi không có kịch bản nào xảy ra trong trường hợp toàn bộ Amazon ngừng hoạt động. Chúng tôi có một kịch bản tương tự đối với Nga. Ở Nga, chúng tôi được tổ chức bởi một nhà cung cấp, từ đó chúng tôi đã chọn có một số trang web. Và một năm trước, chúng tôi đã gặp phải một vấn đề: mặc dù đây là hai trung tâm dữ liệu, nhưng có thể đã có vấn đề ở cấp độ cấu hình mạng của nhà cung cấp và vẫn sẽ ảnh hưởng đến cả hai trung tâm dữ liệu. Và chúng tôi có thể không có sẵn trên cả hai trang web. Tất nhiên đó là những gì đã xảy ra. Cuối cùng chúng tôi đã xem xét lại kiến trúc bên trong. Nó không thay đổi nhiều, nhưng đối với Nga, chúng tôi hiện có hai trang web, không phải từ cùng một nhà cung cấp mà từ hai trang khác nhau. Nếu một cái thất bại, chúng ta có thể chuyển sang cái kia.
Theo giả thuyết, đối với Amazon, chúng tôi đang xem xét khả năng đặt chỗ ở cấp độ của nhà cung cấp khác; có thể là Google, có thể là người khác... Nhưng cho đến nay, trên thực tế, chúng tôi đã quan sát thấy rằng mặc dù Amazon gặp sự cố ở cấp độ một vùng sẵn sàng, nhưng sự cố ở cấp độ toàn bộ khu vực là khá hiếm. Do đó, về mặt lý thuyết, chúng tôi có ý tưởng rằng chúng tôi có thể đặt chỗ “Amazon không phải là Amazon”, nhưng trên thực tế thì điều này vẫn chưa xảy ra.
Một vài lời về tự động hóa
Tự động hóa có luôn cần thiết không? Ở đây thật thích hợp để nhớ lại hiệu ứng Dunning-Kruger. Trên trục “x” là kiến thức và kinh nghiệm mà chúng ta thu được, còn trên trục “y” là sự tự tin trong hành động của chúng ta. Lúc đầu chúng ta không biết gì và không chắc chắn chút nào. Sau đó, chúng ta biết một chút và trở nên cực kỳ tự tin - đây được gọi là “đỉnh cao của sự ngu ngốc”, được minh họa rõ ràng bằng bức tranh “mất trí nhớ và lòng dũng cảm”. Sau đó, chúng tôi đã học được một chút và sẵn sàng tham gia trận chiến. Sau đó, chúng ta mắc phải một số sai lầm cực kỳ nghiêm trọng và thấy mình rơi vào thung lũng tuyệt vọng, khi dường như chúng ta biết điều gì đó nhưng thực tế là chúng ta không biết nhiều. Sau đó, khi có được kinh nghiệm, chúng ta trở nên tự tin hơn.
Logic của chúng tôi về các công tắc tự động khác nhau đối với một số tai nạn nhất định được mô tả rất rõ ràng bằng biểu đồ này. Chúng tôi bắt đầu - chúng tôi không biết làm gì cả, hầu như mọi công việc đều được thực hiện bằng tay. Sau đó, chúng tôi nhận ra rằng chúng tôi có thể gắn tính năng tự động hóa vào mọi thứ và có thể ngủ yên giấc. Và đột nhiên chúng tôi dẫm phải một cú cào lớn: một kết quả dương tính giả được kích hoạt và chúng tôi chuyển đổi lưu lượng truy cập qua lại khi, theo cách tốt, lẽ ra chúng tôi không nên làm điều này. Hậu quả là quá trình sao chép bị phá vỡ hoặc điều gì đó khác – đây chính là thung lũng của sự tuyệt vọng. Và sau đó chúng ta hiểu rằng chúng ta phải tiếp cận mọi thứ một cách khôn ngoan. Nghĩa là, việc dựa vào tự động hóa sẽ tạo ra khả năng xảy ra cảnh báo sai. Nhưng! nếu hậu quả có thể tàn khốc, thì tốt hơn hết hãy giao việc đó cho ca trực, cho các kỹ sư đang làm nhiệm vụ, những người sẽ đảm bảo và giám sát rằng thực sự có tai nạn và sẽ thực hiện các hành động cần thiết theo cách thủ công...
Kết luận
Trong suốt 7 năm, chúng tôi đã đi từ thực tế là khi một thứ gì đó rơi xuống, sẽ có sự hoảng sợ đến hiểu rằng vấn đề không tồn tại, chỉ có những nhiệm vụ, chúng phải - và có thể - được giải quyết. Khi bạn xây dựng một dịch vụ, hãy nhìn nó từ trên cao, đánh giá mọi rủi ro có thể xảy ra. Nếu bạn nhìn thấy chúng ngay lập tức, thì hãy chuẩn bị trước về khả năng dự phòng và khả năng xây dựng cơ sở hạ tầng có khả năng chịu lỗi, bởi vì bất kỳ điểm nào có thể bị lỗi và dẫn đến dịch vụ không thể hoạt động chắc chắn sẽ xảy ra. Và ngay cả khi đối với bạn, có vẻ như một số yếu tố của cơ sở hạ tầng chắc chắn sẽ không bị lỗi - giống như S3, hãy nhớ rằng chúng có thể xảy ra. Và ít nhất về mặt lý thuyết, hãy có ý tưởng về việc bạn sẽ làm gì với chúng nếu có chuyện gì xảy ra. Có kế hoạch quản lý rủi ro. Khi bạn đang nghĩ đến việc thực hiện mọi thứ một cách tự động hoặc thủ công, hãy đánh giá rủi ro: điều gì sẽ xảy ra nếu quá trình tự động hóa bắt đầu chuyển đổi mọi thứ - liệu điều này có dẫn đến tình huống thậm chí còn tồi tệ hơn so với một vụ tai nạn không? Có lẽ ở đâu đó cần phải sử dụng sự thỏa hiệp hợp lý giữa việc sử dụng tự động hóa và phản ứng của kỹ sư đang làm nhiệm vụ, người sẽ đánh giá bức tranh thực tế và hiểu liệu có cần chuyển đổi thứ gì đó ngay tại chỗ hay “có, nhưng không phải bây giờ”.
Một sự thỏa hiệp hợp lý giữa chủ nghĩa hoàn hảo và nỗ lực thực sự, thời gian, tiền bạc mà bạn có thể chi cho kế hoạch mà cuối cùng bạn sẽ có.
Văn bản này là phiên bản cập nhật và mở rộng của báo cáo của Alexander Demidov tại hội nghị .
Nguồn: www.habr.com