Tốt cho tất cả!
Tên tôi là Nikita, tôi là trưởng nhóm kỹ thuật Cian. Một trong những trách nhiệm của tôi tại công ty là giảm số lượng sự cố liên quan đến cơ sở hạ tầng trong sản xuất xuống bằng không.
Những gì sẽ được thảo luận dưới đây khiến chúng tôi rất đau lòng và mục đích của bài viết này là để ngăn người khác lặp lại sai lầm của chúng tôi hoặc ít nhất là giảm thiểu tác động của chúng.
Lời nói đầu
Cách đây rất lâu, khi Cian bao gồm các khối nguyên khối và chưa có gợi ý nào về dịch vụ vi mô, chúng tôi đã đo lường tính khả dụng của tài nguyên bằng cách kiểm tra 3-5 trang.
Họ trả lời - mọi thứ đều ổn, nếu họ không trả lời trong một thời gian dài - hãy cảnh giác. Họ phải nghỉ làm bao lâu để được coi là sự cố do mọi người trong cuộc họp quyết định. Một nhóm kỹ sư luôn tham gia điều tra vụ việc. Khi cuộc điều tra hoàn tất, họ viết một bản khám nghiệm tử thi - một loại báo cáo qua email dưới dạng: chuyện gì đã xảy ra, nó kéo dài bao lâu, chúng tôi đã làm gì vào lúc này, chúng tôi sẽ làm gì trong tương lai.
Các trang chính của trang web hoặc cách chúng tôi hiểu rằng chúng tôi đã chạm đáy
Để phần nào hiểu được mức độ ưu tiên của lỗi, chúng tôi đã xác định các trang quan trọng nhất đối với chức năng kinh doanh. Bằng cách sử dụng chúng, chúng tôi đếm số lượng yêu cầu và thời gian chờ thành công/không thành công. Đây là cách chúng tôi đo thời gian hoạt động.
Giả sử chúng tôi phát hiện ra rằng có một số phần cực kỳ quan trọng của trang web chịu trách nhiệm về dịch vụ chính - tìm kiếm và gửi quảng cáo. Nếu số lượng yêu cầu không thành công vượt quá 1% thì đây là một sự cố nghiêm trọng. Nếu trong vòng 15 phút trong khung giờ vàng mà tỷ lệ lỗi vượt quá 0,1% thì đây cũng được coi là sự cố nghiêm trọng. Các tiêu chí này bao gồm hầu hết các sự cố; phần còn lại nằm ngoài phạm vi của bài viết này.
Top sự cố hay nhất Cyan
Vì vậy, chúng tôi chắc chắn đã học được cách xác định thực tế rằng một sự cố đã xảy ra.
Giờ đây mọi sự việc đều được mô tả chi tiết và phản ánh trong sử thi Jira. Nhân tiện: để làm điều này, chúng tôi đã bắt đầu một dự án riêng, gọi nó là THẤT BẠI - chỉ có thể tạo sử thi trong đó.
Nếu bạn tập hợp tất cả những thất bại trong vài năm qua, những người dẫn đầu là:
- sự cố liên quan đến mssql;
- sự cố do yếu tố bên ngoài gây ra;
- lỗi của quản trị viên.
Chúng ta hãy xem xét chi tiết hơn những sai lầm của quản trị viên, cũng như một số thất bại thú vị khác.
Vị trí thứ năm - “Sắp xếp mọi thứ theo thứ tự trong DNS”
Đó là một ngày thứ ba giông bão. Chúng tôi quyết định lập lại trật tự trong cụm DNS.
Tôi muốn chuyển các máy chủ DNS nội bộ từ liên kết sang powerdns, phân bổ các máy chủ hoàn toàn riêng biệt cho việc này, nơi không có gì ngoại trừ DNS.
Chúng tôi đã đặt một máy chủ DNS ở mỗi vị trí trong DC của mình và đã đến lúc chuyển các vùng từ liên kết sang powerdns và chuyển cơ sở hạ tầng sang máy chủ mới.
Trong quá trình di chuyển, trong số tất cả các máy chủ được chỉ định trong bộ nhớ đệm cục bộ sẽ liên kết trên tất cả các máy chủ, chỉ còn lại một máy chủ nằm ở trung tâm dữ liệu ở St. Petersburg. DC này ban đầu được tuyên bố là không quan trọng đối với chúng tôi, nhưng đột nhiên trở thành một điểm lỗi duy nhất.
Chính trong thời kỳ di dời này, con kênh nối Moscow và St. Petersburg đã bị sập. Chúng tôi thực sự đã không có DNS trong năm phút và đã khôi phục được khi nhà cung cấp dịch vụ lưu trữ khắc phục sự cố.
Kết luận:
Nếu trước đây chúng ta bỏ qua những yếu tố bên ngoài trong quá trình chuẩn bị cho công việc thì giờ đây chúng cũng nằm trong danh sách những gì chúng ta đang chuẩn bị. Và bây giờ chúng tôi cố gắng đảm bảo rằng tất cả các thành phần đều được bảo lưu n-2 và trong quá trình làm việc, chúng tôi có thể hạ mức này xuống n-1.
- Khi lập kế hoạch hành động, hãy đánh dấu trước những điểm mà dịch vụ có thể thất bại và suy nghĩ trước về tình huống mà mọi thứ “từ tồi tệ trở nên tồi tệ hơn”.
- Phân phối các máy chủ DNS nội bộ trên các vị trí địa lý/trung tâm dữ liệu/giá đỡ/bộ chuyển mạch/đầu vào khác nhau.
- Trên mỗi máy chủ, hãy cài đặt một máy chủ DNS bộ đệm cục bộ, máy chủ này sẽ chuyển hướng các yêu cầu đến các máy chủ DNS chính và nếu không có sẵn, nó sẽ phản hồi từ bộ đệm.
Vị trí thứ tư - “Sắp xếp mọi thứ trong Nginx”
Một ngày đẹp trời, nhóm của chúng tôi quyết định rằng “chúng tôi đã có đủ thứ này” và quá trình tái cấu trúc cấu hình nginx bắt đầu. Mục tiêu chính là đưa các cấu hình về một cấu trúc trực quan. Trước đây, mọi thứ đều được “xây dựng theo lịch sử” và không mang bất kỳ logic nào. Bây giờ mỗi server_name đã được chuyển sang một tệp cùng tên và tất cả các cấu hình đã được phân bổ vào các thư mục. Nhân tiện, cấu hình chứa 253949 dòng hoặc 7836520 ký tự và chiếm gần 7 megabyte. Cấu trúc cấp cao nhất:
Cấu trúc Nginx
├── access
│ ├── allow.list
...
│ └── whitelist.conf
├── geobase
│ ├── exclude.conf
...
│ └── geo_ip_to_region_id.conf
├── geodb
│ ├── GeoIP.dat
│ ├── GeoIP2-Country.mmdb
│ └── GeoLiteCity.dat
├── inc
│ ├── error.inc
...
│ └── proxy.inc
├── lists.d
│ ├── bot.conf
...
│ ├── dynamic
│ └── geo.conf
├── lua
│ ├── cookie.lua
│ ├── log
│ │ └── log.lua
│ ├── logics
│ │ ├── include.lua
│ │ ├── ...
│ │ └── utils.lua
│ └── prom
│ ├── stats.lua
│ └── stats_prometheus.lua
├── map.d
│ ├── access.conf
│ ├── ..
│ └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│ ├── cian.ru
│ │ ├── cian.ru.conf
│ │ ├── ...
│ │ └── my.cian.ru.conf
├── service.d
│ ├── ...
│ └── status.conf
└── upstream.d
├── cian-mcs.conf
├── ...
└── wafserver.confNó đã trở nên tốt hơn nhiều, nhưng trong quá trình đổi tên và phân phối cấu hình, một số trong số chúng có phần mở rộng sai và không được đưa vào chỉ thị include *.conf. Kết quả là một số máy chủ không còn khả dụng và trả lại 301 về trang chính. Do mã phản hồi không phải là 5xx/4xx nên điều này không được chú ý ngay lập tức mà chỉ đến buổi sáng. Sau đó, chúng tôi bắt đầu viết bài kiểm tra để kiểm tra các thành phần cơ sở hạ tầng.
Kết luận:
- Cấu trúc cấu hình của bạn một cách chính xác (không chỉ nginx) và suy nghĩ kỹ về cấu trúc ở giai đoạn đầu của dự án. Bằng cách này, bạn sẽ làm cho chúng dễ hiểu hơn đối với nhóm, điều này sẽ làm giảm TTM.
- Viết bài kiểm tra cho một số thành phần cơ sở hạ tầng. Ví dụ: kiểm tra xem tất cả các tên máy chủ khóa có cung cấp trạng thái + nội dung phản hồi chính xác hay không. Chỉ cần có sẵn một vài tập lệnh kiểm tra các chức năng cơ bản của thành phần là đủ, để lúc 3 giờ sáng không phải điên cuồng nhớ lại những gì cần kiểm tra.
Vị trí thứ ba - “Đột nhiên hết chỗ trong Cassandra”
Dữ liệu tăng trưởng ổn định và mọi thứ đều ổn cho đến thời điểm việc sửa chữa các không gian hộp lớn bắt đầu thất bại trong cụm Cassandra vì quá trình nén không thể hoạt động trên chúng.
Một ngày giông bão, chùm gần như biến thành quả bí ngô, cụ thể là:
- có khoảng 20% tổng dung lượng còn lại trong cụm;
- Không thể thêm đầy đủ các nút vì quá trình dọn dẹp không diễn ra sau khi thêm nút do thiếu dung lượng trên các phân vùng;
- năng suất giảm dần do đầm nén không hoạt động;
- Cụm đang ở chế độ khẩn cấp.
Thoát - chúng tôi đã thêm 5 nút nữa mà không cần dọn dẹp, sau đó chúng tôi bắt đầu xóa chúng khỏi cụm một cách có hệ thống và nhập lại chúng, giống như các nút trống đã hết dung lượng. Đã dành nhiều thời gian hơn chúng ta mong muốn. Có nguy cơ cụm không có sẵn một phần hoặc toàn bộ.
Kết luận:
- Trên tất cả các máy chủ cassandra, không nên chiếm quá 60% dung lượng trên mỗi phân vùng.
- Chúng nên được tải ở mức CPU không quá 50%.
- Bạn không nên quên việc lập kế hoạch năng lực và cần suy nghĩ kỹ lưỡng về từng thành phần, dựa trên các chi tiết cụ thể của nó.
- Càng nhiều nút trong cụm thì càng tốt. Các máy chủ chứa một lượng nhỏ dữ liệu sẽ bị quá tải nhanh hơn và một cụm như vậy sẽ dễ dàng phục hồi hơn.
Vị trí thứ hai - “Dữ liệu biến mất khỏi bộ lưu trữ khóa-giá trị lãnh sự”
Để khám phá dịch vụ, chúng tôi cũng như nhiều người khác, sử dụng lãnh sự. Nhưng chúng tôi cũng sử dụng khóa-giá trị của nó cho bố cục màu xanh lam của khối nguyên khối. Nó lưu trữ thông tin về các luồng ngược dòng đang hoạt động và không hoạt động, những luồng này sẽ thay đổi địa điểm trong quá trình triển khai. Với mục đích này, một dịch vụ triển khai đã được viết để tương tác với KV. Tại một thời điểm nào đó, dữ liệu từ KV biến mất. Đã khôi phục từ bộ nhớ nhưng có một số lỗi. Kết quả là trong quá trình tải lên, tải trên các luồng lên được phân bổ không đồng đều và chúng tôi đã gặp nhiều lỗi 502 do các phần phụ trợ bị quá tải trên CPU. Kết quả là, chúng tôi đã chuyển từ lãnh sự KV sang postgres, từ đó việc loại bỏ chúng không còn dễ dàng nữa.
Kết luận:
- Các dịch vụ không có sự cho phép không được chứa dữ liệu quan trọng đối với hoạt động của trang web. Ví dụ: nếu bạn không có quyền trong ES, tốt hơn là từ chối quyền truy cập ở cấp độ mạng từ mọi nơi không cần thiết, chỉ để lại những quyền cần thiết và cũng đặt action.structive_requires_name: true.
- Thực hành trước cơ chế sao lưu và phục hồi của bạn. Ví dụ: tạo trước một tập lệnh (ví dụ bằng python) có thể sao lưu và khôi phục.
Vị trí đầu tiên - “Thuyền trưởng không rõ ràng”
Tại một số thời điểm, chúng tôi nhận thấy sự phân bổ tải không đồng đều trên nginx ngược dòng trong trường hợp có hơn 10 máy chủ ở phần phụ trợ. Do thực tế là các yêu cầu quay vòng gửi từ luồng đầu tiên đến luồng cuối cùng theo thứ tự và mỗi lần tải lại nginx lại bắt đầu lại, các luồng ngược đầu tiên luôn nhận được nhiều yêu cầu hơn các luồng còn lại, kết quả là chúng hoạt động chậm hơn và toàn bộ trang web bị ảnh hưởng. Điều này ngày càng trở nên đáng chú ý khi lưu lượng truy cập tăng lên. Việc chỉ cập nhật nginx để kích hoạt ngẫu nhiên không hoạt động - chúng tôi cần làm lại một loạt mã lua không hoạt động trên phiên bản 1 (tại thời điểm đó). Chúng tôi đã phải vá nginx 1.15, đưa ra hỗ trợ ngẫu nhiên cho nó. Điều này đã giải quyết được vấn đề. Lỗi này chiến thắng ở hạng mục “Đội trưởng không rõ ràng”.
Kết luận:
Thật thú vị và hấp dẫn khi khám phá lỗi này).
- Tổ chức việc theo dõi của bạn để giúp bạn phát hiện những biến động đó một cách nhanh chóng. Ví dụ: bạn có thể sử dụng ELK để theo dõi rps trên mỗi phần phụ trợ của từng luồng ngược, theo dõi thời gian phản hồi của chúng theo quan điểm của nginx. Trong trường hợp này, điều này đã giúp chúng tôi xác định được vấn đề.
Kết quả là, hầu hết các thất bại có thể tránh được bằng cách tiếp cận thận trọng hơn với những gì bạn đang làm. Chúng ta phải luôn nhớ định luật Murphy: Cái gì có thể sai thì sẽ sai, và xây dựng các thành phần dựa trên nó.
Nguồn: www.habr.com