Hội thảo trực tuyến có âm thanh kém nên chúng tôi đã ghi lại.
Tên tôi là Medvedev Eduard. Hôm nay tôi sẽ nói về SRE là gì, SRE xuất hiện như thế nào, tiêu chí công việc dành cho kỹ sư SRE là gì, một chút về tiêu chí độ tin cậy, một chút về việc giám sát nó. Chúng ta sẽ nói phần trên vì bạn không thể nói nhiều trong một giờ, nhưng tôi sẽ cung cấp cho bạn tài liệu để bạn xem xét thêm và tất cả chúng tôi đang đợi bạn tại . ở Moscow vào cuối tháng Giêng.
Đầu tiên, hãy nói về SRE - Kỹ thuật độ tin cậy của trang web - là gì. Và làm thế nào nó xuất hiện như một vị trí riêng biệt, như một hướng đi riêng biệt. Mọi chuyện bắt đầu từ thực tế là trong giới phát triển truyền thống, Dev và Ops là hai nhóm hoàn toàn khác nhau, thường có hai mục tiêu hoàn toàn khác nhau. Mục tiêu của nhóm phát triển là tung ra các tính năng mới để đáp ứng nhu cầu kinh doanh. Mục tiêu của nhóm Ops là đảm bảo mọi thứ hoạt động và không có gì bị hỏng. Rõ ràng, những mục tiêu này mâu thuẫn trực tiếp với nhau: để mọi thứ hoạt động tốt và không có gì hỏng hóc, tốt hơn hết là bạn nên tung ra các tính năng mới càng ít càng tốt. Do đó, nhiều xung đột nội bộ nảy sinh mà phương pháp mà ngày nay gọi là DevOps đang cố gắng giải quyết.
Vấn đề là chúng ta chưa có định nghĩa rõ ràng về DevOps và cách triển khai DevOps rõ ràng. Tôi đã phát biểu tại một hội nghị ở Yekaterinburg cách đây 2 năm và cho đến nay phần DevOps đều bắt đầu bằng báo cáo “DevOps là gì”. Vào năm 2017, devops đã gần 10 tuổi nhưng chúng tôi vẫn đang tranh cãi xem nó là gì. Và đây là một tình huống rất kỳ lạ mà Google đã cố gắng giải quyết vài năm trước.
Vào năm 2016, Google đã phát hành một cuốn sách có tên “Kỹ thuật về độ tin cậy của trang web”. Và trên thực tế, chính từ cuốn sách này mà phong trào SRE đã bắt đầu. SRE là một lựa chọn cụ thể để triển khai mô hình DevOps trong một công ty cụ thể. Các kỹ sư của SRE đặt ra cho mình mục tiêu là đảm bảo hệ thống vận hành đáng tin cậy. Chúng chủ yếu được lấy từ các nhà phát triển, đôi khi từ các quản trị viên có nền tảng phát triển vững vàng. Và họ làm những gì mà quản trị viên hệ thống thường làm, nhưng nền tảng vững chắc về phát triển và kiến thức về hệ thống từ quan điểm mã dẫn đến thực tế là những người này không thiên về công việc hành chính thông thường mà thiên về tự động hóa.
Hóa ra mô hình DevOps trong các nhóm SRE được triển khai bởi thực tế là có các kỹ sư SRE giải quyết các vấn đề về cấu trúc. Đây rồi, mối liên hệ giữa Dev và Ops mà mọi người đã nói đến suốt 8 năm qua. Vai trò của SRE tương tự như vai trò của kiến trúc sư ở chỗ người mới vào nghề không trở thành SRE. Những người mới bắt đầu sự nghiệp đều chưa có kinh nghiệm và chưa có kiến thức sâu rộng cần thiết. Bởi vì SRE đòi hỏi kiến thức rất phức tạp về chính xác điều gì và khi nào chính xác có thể xảy ra sai sót. Vì vậy, theo quy luật, ở đây cần có một số loại kinh nghiệm, cả trong và ngoài công ty.
Họ hỏi liệu sự khác biệt giữa SRE và devops có được mô tả hay không. Cô ấy vừa được mô tả. Chúng ta có thể nói về vị trí của SRE trong tổ chức. Không giống như cách tiếp cận DevOps cổ điển, trong đó Ops vẫn là một bộ phận riêng biệt, SRE là một phần của nhóm phát triển. Họ tham gia vào việc phát triển sản phẩm. Thậm chí còn có một cách tiếp cận trong đó SRE là một vai trò được chuyển từ nhà phát triển này sang nhà phát triển khác. Ví dụ: họ tham gia đánh giá mã giống như các nhà thiết kế UX, nhà phát triển và đôi khi là người quản lý sản phẩm. SRE hoạt động ở cùng cấp độ này. Chúng tôi cần sự chấp thuận của họ, chúng tôi cần sự xem xét của họ, để đối với mỗi lần triển khai, SRE cho biết: “Được rồi, việc triển khai này, sản phẩm này sẽ không ảnh hưởng tiêu cực đến độ tin cậy. Và nếu có thì nó sẽ nằm trong một số giới hạn có thể chấp nhận được.” Chúng ta cũng sẽ nói về điều này.
Theo đó, SRE có quyền phủ quyết đối với việc thay đổi quy tắc. Và nhìn chung, điều này cũng dẫn đến một số xung đột nhỏ nếu SRE được triển khai không đúng cách. Trong chính cuốn sách về Kỹ thuật độ tin cậy của trang web, nhiều phần, thậm chí nhiều phần, cho biết cách tránh những xung đột này.
Mọi người hỏi SRE liên quan đến bảo mật thông tin như thế nào. SRE không liên quan trực tiếp đến vấn đề bảo mật thông tin. Hầu hết ở các công ty lớn, việc này được thực hiện bởi từng cá nhân, người thử nghiệm và nhà phân tích. Nhưng SRE cũng tương tác với họ theo nghĩa là một số hoạt động, một số cam kết, một số triển khai ảnh hưởng đến bảo mật cũng có thể ảnh hưởng đến tính khả dụng của sản phẩm. Vì vậy, SRE nói chung có sự tương tác với bất kỳ nhóm nào, kể cả nhóm bảo mật, kể cả các nhà phân tích. Do đó, SRE chủ yếu cần thiết khi cố gắng triển khai DevOps, nhưng gánh nặng đối với các nhà phát triển lại trở nên quá lớn. Nghĩa là, bản thân nhóm phát triển không còn có thể đương đầu với thực tế là giờ đây họ cũng cần phải chịu trách nhiệm về Ops. Và một vai trò riêng biệt xuất hiện. Vai trò này được lên kế hoạch trong ngân sách. Đôi khi vai trò này được xây dựng phù hợp với quy mô của nhóm, một người riêng biệt xuất hiện, đôi khi một trong những nhà phát triển trở thành người đó. Đây là cách SRE đầu tiên xuất hiện trong nhóm.
Độ phức tạp của hệ thống bị ảnh hưởng bởi SRE, độ phức tạp ảnh hưởng đến độ tin cậy vận hành, có thể là cần thiết hoặc ngẫu nhiên. Độ phức tạp cần thiết là khi độ phức tạp của sản phẩm tăng đến mức mà các tính năng của sản phẩm mới yêu cầu. Độ phức tạp ngẫu nhiên là khi độ phức tạp của hệ thống tăng lên nhưng tính năng sản phẩm và yêu cầu nghiệp vụ không ảnh hưởng trực tiếp đến điều này. Hóa ra là nhà phát triển đã mắc lỗi ở đâu đó hoặc thuật toán không tối ưu hoặc một số lợi ích bổ sung được đưa vào làm tăng độ phức tạp của sản phẩm một cách không cần thiết. Một SRE tốt phải luôn tránh được tình trạng này. Nghĩa là, mọi cam kết, triển khai, mọi yêu cầu kéo làm tăng độ phức tạp do bổ sung ngẫu nhiên đều phải bị chặn.
Câu hỏi đặt ra là tại sao không thuê một kỹ sư, một quản trị viên hệ thống có nhiều kiến thức về gia nhập nhóm. Chúng tôi được biết, một nhà phát triển trong vai trò kỹ sư không phải là giải pháp nhân sự tối ưu nhất. Nhà phát triển trong vai trò kỹ sư không phải lúc nào cũng là giải pháp nhân sự tối ưu, nhưng vấn đề ở đây là nhà phát triển tham gia Ops có mong muốn tự động hóa hơn một chút, có thêm một chút kiến thức và kỹ năng để thực hiện việc này tự động hóa. Và theo đó, chúng tôi không chỉ giảm thời gian cho một số hoạt động cụ thể, không chỉ quy trình mà còn cả các thông số kinh doanh quan trọng như MTTR (Thời gian trung bình để phục hồi, thời gian phục hồi). Vì vậy, và chúng ta cũng sẽ nói về điều này sau, chúng ta sẽ tiết kiệm được tiền cho tổ chức.
Bây giờ hãy nói về các tiêu chí cho công việc SRE. Và trước hết là về độ tin cậy. Ở các công ty nhỏ và các công ty khởi nghiệp, người ta thường cho rằng nếu dịch vụ được viết tốt, nếu sản phẩm được viết tốt và chính xác thì sẽ hoạt động, không bị hỏng. Thế là xong, chúng ta viết code tốt nên không có gì phải hỏng cả. Mã rất đơn giản, không có gì để phá vỡ. Đây cũng chính là những người nói rằng chúng tôi không cần xét nghiệm, bởi vì, hãy nhìn xem, đây là ba phương pháp VPI, tại sao phải bận tâm?
Tất nhiên điều này là sai. Và những người này thường bị tổn thương bởi loại mã này trong thực tế, bởi vì mọi thứ đều bị hỏng. Mọi thứ đôi khi đổ vỡ theo những cách khó lường nhất. Đôi khi người ta nói không, điều đó sẽ không bao giờ xảy ra. Và nó vẫn xảy ra. Xảy ra khá thường xuyên. Và đó là lý do tại sao không ai cố gắng đạt được mức độ sẵn sàng 100%, bởi vì mức độ sẵn sàng 100% không bao giờ xảy ra. Đây là tiêu chuẩn. Và đó là lý do tại sao chúng ta luôn nói về số chín khi nói về tính sẵn có của dịch vụ. 2 số chín, 3 số chín, 4 số chín, 5 số chín. Nếu chúng ta dịch điều này thành thời gian ngừng hoạt động, thì ví dụ: 5 giờ là thời gian ngừng hoạt động nhiều hơn 5 phút mỗi năm một chút, 2 giờ là 3,5 ngày ngừng hoạt động.
Nhưng rõ ràng là đến một lúc nào đó POI và lợi tức đầu tư sẽ giảm. Chuyển từ hai số chín xuống còn ba số chín có nghĩa là giảm thời gian ngừng hoạt động hơn 3 ngày. Đi từ 47 giờ đến XNUMX giờ giúp giảm thời gian ngừng hoạt động XNUMX phút mỗi năm. Và hóa ra điều này có thể không quan trọng đối với hoạt động kinh doanh. Và nói chung, độ tin cậy cần thiết không phải là vấn đề kỹ thuật, trước hết đó là vấn đề kinh doanh, đó là vấn đề sản phẩm. Mức độ ngừng hoạt động nào có thể chấp nhận được đối với người dùng sản phẩm, họ mong đợi điều gì, họ phải trả bao nhiêu, ví dụ như họ mất bao nhiêu tiền, hệ thống mất bao nhiêu tiền.
Một câu hỏi quan trọng là độ tin cậy của các thành phần còn lại là gì. Bởi vì sự khác biệt giữa 4 và 5 số chín sẽ không thể hiện rõ trên điện thoại thông minh có 2 số chín đáng tin cậy. Nói một cách đại khái, nếu có thứ gì đó xảy ra trên điện thoại thông minh trong dịch vụ của bạn 10 lần một năm, rất có thể 8 lần sự cố đã xảy ra ở phía hệ điều hành. Người dùng đã quen với điều này và sẽ không chú ý đến nó thêm một lần nữa trong một năm. Cần phải so sánh cái giá của việc tăng độ tin cậy và tăng lợi nhuận.
Chỉ trong cuốn sách về SRE có một ví dụ điển hình về việc tăng lên 4 số chín từ 3 số chín. Nó chỉ ra rằng mức độ sẵn có tăng lên ít hơn 0,1%. Và nếu doanh thu của dịch vụ là 1 triệu USD mỗi năm thì mức tăng doanh thu là 900 USD. Nếu việc tăng số lượng sẵn có lên 900 khiến chúng tôi tốn ít hơn 900 USD mỗi năm thì mức tăng này có ý nghĩa về mặt tài chính. Nếu chi phí hơn 3 đô la một năm thì điều đó không còn ý nghĩa nữa vì doanh thu tăng lên không bù đắp được chi phí lao động và chi phí tài nguyên. Và XNUMX số chín sẽ là đủ đối với chúng tôi.
Tất nhiên đây là một ví dụ đơn giản trong đó tất cả các yêu cầu đều như nhau. Và từ 3 chín đến 4 chín thì khá dễ dàng, nhưng đồng thời, chẳng hạn, đi từ 2 chín lên 3 đã tiết kiệm được 9 nghìn đô la, nó có thể có ý nghĩa về mặt tài chính. Đương nhiên, trong thực tế, việc không đăng ký được một yêu cầu còn tệ hơn việc không hiển thị được một trang; các yêu cầu có trọng số khác nhau. Họ có thể có các tiêu chí hoàn toàn khác nhau từ quan điểm kinh doanh, nhưng theo quy luật, nếu chúng ta không nói về bất kỳ dịch vụ cụ thể nào thì đây là một ước tính khá đáng tin cậy.
Chúng tôi nhận được câu hỏi liệu SRE có phải là một trong những đơn vị điều phối khi lựa chọn giải pháp kiến trúc cho dịch vụ hay không. Điều này có thể chấp nhận được về mặt tích hợp vào cơ sở hạ tầng hiện có để không làm mất đi tính ổn định của nó. Có, SRE ảnh hưởng đến các yêu cầu kéo, cam kết, phát hành theo cách tương tự; chúng ảnh hưởng đến kiến trúc, việc triển khai các dịch vụ mới, vi dịch vụ và việc triển khai các giải pháp mới. Tại sao trước đây tôi lại nói là cần kinh nghiệm, cần bằng cấp. Trên thực tế, SRE là một trong những tiếng nói cản trở mọi giải pháp kiến trúc và phần mềm. Theo đó, một SRE với tư cách là một kỹ sư, trước hết, không chỉ phải hiểu mà còn phải hiểu một số quyết định cụ thể sẽ ảnh hưởng như thế nào đến độ tin cậy, tính ổn định và hiểu điều này liên quan như thế nào đến nhu cầu kinh doanh và điều này có thể được chấp nhận từ quan điểm nào. , và cái nào không.
Do đó, bây giờ là lúc nói về tiêu chí độ tin cậy, trong SRE được định nghĩa theo truyền thống là SLA (Thỏa thuận cấp độ dịch vụ). Rất có thể là một thuật ngữ quen thuộc. SLI (Chỉ báo mức dịch vụ). SLO (Mục tiêu cấp độ dịch vụ). Thỏa thuận cấp độ dịch vụ có lẽ là một điều khoản quan trọng, đặc biệt nếu bạn đã làm việc với các mạng, nhà cung cấp và dịch vụ lưu trữ. Đây là một thỏa thuận chung mô tả hiệu suất của toàn bộ dịch vụ của bạn, các hình phạt, một số hình phạt đối với các lỗi, số liệu, tiêu chí. Và SLI chính là thước đo khả năng tiếp cận. Đó là, SLI có thể là gì: thời gian phản hồi từ dịch vụ, số lỗi tính theo phần trăm. Đây có thể là băng thông nếu chúng ta đang nói về một số loại lưu trữ tệp. Nếu chúng ta đang nói về các thuật toán nhận dạng, chẳng hạn, chỉ báo thậm chí có thể là tính chính xác của câu trả lời. SLO (Mục tiêu cấp độ dịch vụ) tương ứng là sự kết hợp của chỉ báo SLI, giá trị và khoảng thời gian của nó.
Giả sử SLA có thể như thế này. Dịch vụ này có sẵn 99,95% thời gian trong suốt cả năm. Hoặc 99 phiếu hỗ trợ kỹ thuật quan trọng sẽ bị đóng trong vòng 3 giờ mỗi quý. Hoặc 85% truy vấn sẽ được trả lời trong vòng 1,5 giây mỗi tháng. Nghĩa là, chúng ta đang dần hiểu rằng sai sót và thất bại là điều khá bình thường. Đây là một tình huống có thể chấp nhận được, chúng tôi đang lên kế hoạch cho nó, thậm chí chúng tôi còn trông cậy vào nó ở một mức độ nào đó. Nghĩa là, SRE xây dựng các hệ thống có thể mắc lỗi, phải phản ứng bình thường với các lỗi và phải tính đến các lỗi đó. Và nếu có thể, họ nên xử lý lỗi theo cách mà người dùng không nhận thấy hoặc nhận thấy chúng, nhưng có một số cách giải quyết để mọi thứ không bị hỏng hoàn toàn.
Ví dụ: nếu bạn tải video lên YouTube và YouTube không thể chuyển đổi video đó ngay lập tức, nếu video quá lớn, nếu định dạng không tối ưu thì yêu cầu đương nhiên sẽ không thành công khi hết thời gian chờ, YouTube sẽ không hiển thị 502 lỗi, YouTube sẽ thông báo: “Chúng tôi đã tạo mọi thứ, video của bạn đang được xử lý. Nó sẽ sẵn sàng trong khoảng 10 phút nữa.” Đây là nguyên tắc xuống cấp một cách duyên dáng, chẳng hạn như nguyên tắc này quen thuộc với quá trình phát triển front-end nếu bạn đã từng làm điều này.
Các thuật ngữ tiếp theo mà chúng ta sẽ nói đến, rất quan trọng để làm việc với độ tin cậy, với lỗi, với kỳ vọng, là MTBF và MTTR. MTBF là thời gian trung bình giữa các lần thất bại. MTTR Thời gian trung bình để phục hồi, thời gian trung bình để phục hồi. Tức là bao nhiêu thời gian đã trôi qua kể từ thời điểm phát hiện ra lỗi, từ thời điểm xuất hiện lỗi cho đến thời điểm dịch vụ được khôi phục hoạt động hoàn toàn bình thường. MTBF chủ yếu được khắc phục bằng cách cải thiện chất lượng mã. Đó là thực tế là SRE có thể nói “không”. Và toàn đội cần hiểu rằng khi SRE nói “không”, anh ấy nói điều đó không phải vì anh ấy có hại, không phải vì anh ấy xấu mà vì nếu không thì mọi người sẽ đau khổ.
Một lần nữa, có rất nhiều bài viết, rất nhiều phương pháp, rất nhiều cách, thậm chí trong chính cuốn sách mà tôi thường tham khảo, làm thế nào để đảm bảo rằng các nhà phát triển khác không bắt đầu ghét SRE. Mặt khác, MTTR là về việc thực hiện SLO (Mục tiêu cấp độ dịch vụ) của bạn. Và điều này chủ yếu là tự động hóa. Bởi vì, ví dụ, SLO của chúng tôi có thời gian hoạt động là 4 giờ mỗi quý. Điều này có nghĩa là trong 3 tháng, chúng tôi có thể cho phép ngừng hoạt động 13 phút. Và hóa ra MTTR của chúng tôi không thể dài hơn 13 phút. Nếu chúng tôi dành 13 phút để phản ứng với ít nhất 1 lần ngừng hoạt động, điều này có nghĩa là chúng tôi đã sử dụng hết toàn bộ ngân sách trong quý. Chúng tôi đang vi phạm SLO. 13 phút để phản ứng và sửa lỗi là rất nhiều đối với một cỗ máy nhưng lại rất ít đối với một con người. Bởi vì tính đến thời điểm một người nhận được cảnh báo, tính đến thời điểm anh ta phản ứng, tính đến thời điểm anh ta phát hiện ra lỗi thì đã là vài phút. Sẽ mất thêm vài phút nữa cho đến khi một người hiểu được cách khắc phục, chính xác là cần khắc phục những gì, phải làm gì. Và trên thực tế, ngay cả khi bạn chỉ cần khởi động lại máy chủ hoặc nâng cấp một nút mới, thì MTTR theo cách thủ công sẽ mất khoảng 7-8 phút. Khi tự động hóa một quy trình, MTTR thường đạt tới một giây, đôi khi là mili giây. Google thường nói về mili giây, nhưng trên thực tế, tất nhiên mọi thứ không được tốt như vậy.
Lý tưởng nhất là SRE gần như nên tự động hóa hoàn toàn công việc của mình vì điều này ảnh hưởng trực tiếp đến MTTR, các số liệu của nó, SLO của toàn bộ dịch vụ và theo đó là lợi nhuận kinh doanh. Nếu quá thời gian, chúng tôi sẽ được hỏi liệu lỗi có nằm ở SRE hay không. May mắn thay, lỗi không đổ lên đầu ai cả. Và đây là một nền văn hóa riêng biệt, được gọi là khám nghiệm tử thi không cần dưỡng chất, mà hôm nay chúng ta sẽ không nói đến mà sẽ phân tích tại Slurm. Đây là một chủ đề rất thú vị có thể được nói đến rất nhiều. Nói một cách đại khái, nếu vượt quá thời gian quy định trong mỗi quý thì mọi người đều có lỗi một chút, nghĩa là đổ lỗi cho mọi người sẽ không hiệu quả, thay vào đó, có lẽ chúng ta đừng đổ lỗi cho ai mà hãy khắc phục tình hình và làm việc với những gì mình có. Theo kinh nghiệm của tôi, cách tiếp cận này hơi xa lạ với hầu hết các đội, đặc biệt là ở Nga, nhưng nó có ý nghĩa và hoạt động rất tốt. Vì vậy, cuối cùng tôi sẽ giới thiệu các bài báo và tài liệu mà bạn có thể đọc về chủ đề này. Hoặc đến với Slurm SRE.
Hãy để tôi giải thích. Nếu vượt quá thời gian SLO mỗi quý, nếu thời gian ngừng hoạt động không phải là 13 phút mà là 15 phút, thì ai có thể chịu trách nhiệm về điều này? Tất nhiên, SRE có thể có lỗi vì rõ ràng nó đã thực hiện một số cam kết hoặc triển khai không tốt. Quản trị viên trung tâm dữ liệu có thể phải chịu trách nhiệm về điều này vì anh ta có thể đã thực hiện một số hoạt động bảo trì đột xuất. Nếu quản trị viên trung tâm dữ liệu chịu trách nhiệm về việc này thì người ở Ops cũng phải chịu trách nhiệm vì đã không tính toán bảo trì khi đồng ý với SLO. Đây là lỗi của người quản lý, giám đốc kỹ thuật hoặc người đã ký hợp đồng trung tâm dữ liệu và không chú ý đến việc SLA của trung tâm dữ liệu không được thiết kế cho thời gian ngừng hoạt động cần thiết. Theo đó, mọi người đều có phần đáng trách trong tình huống này. Và điều đó có nghĩa là không có ích gì khi đổ lỗi cho bất kỳ ai cụ thể trong tình huống này. Nhưng tất nhiên nó cần phải được sửa chữa. Đó là lý do tại sao việc khám nghiệm tử thi tồn tại. Và nếu bạn đọc, chẳng hạn, GitHub postmortems, và đây luôn là một câu chuyện rất thú vị, nhỏ và bất ngờ trong từng trường hợp cụ thể, bạn có thể thay thế rằng không ai từng nói rằng người cụ thể này là người đáng trách. Đổ lỗi luôn được đổ lỗi cho các quy trình thiếu sót cụ thể.
Hãy chuyển sang câu hỏi tiếp theo. Tự động hóa. Thông thường, khi nói về tự động hóa trong các bối cảnh khác, tôi thường đề cập đến một bảng nói về khoảng thời gian bạn có thể thực hiện tự động hóa một tác vụ để không mất nhiều thời gian tự động hóa nó hơn mức bạn thường tiết kiệm. Có một nhược điểm. Điều đáng chú ý là khi SRE tự động hóa một nhiệm vụ, họ không chỉ tiết kiệm thời gian mà còn tiết kiệm tiền vì tự động hóa tác động trực tiếp đến MTTR. Có thể nói, họ tiết kiệm được tinh thần của nhân viên và nhà phát triển, đây cũng là một nguồn tài nguyên có thể cạn kiệt. Họ giảm bớt thói quen. Và tất cả những điều này đều có tác động tích cực đến công việc và do đó, đối với hoạt động kinh doanh, ngay cả khi có vẻ như việc tự động hóa không có ý nghĩa gì về mặt chi phí thời gian.
Trên thực tế, điều đó hầu như luôn xảy ra và có rất ít trường hợp không đáng để tự động hóa một cái gì đó trong vai trò SRE. Tiếp theo chúng ta sẽ nói về cái được gọi là quỹ lỗi, quỹ lỗi. Trên thực tế, hóa ra là nếu bạn đang làm tốt hơn đáng kể so với SLO mà bạn đặt ra cho mình thì điều này cũng không tốt lắm. Điều này khá tệ vì SLO không chỉ hoạt động như giới hạn dưới mà còn hoạt động như giới hạn trên gần đúng. Khi bạn đặt cho mình một SLO có sẵn là 99% và trên thực tế là bạn có 99,99%, hóa ra là bạn có một số không gian để thử nghiệm, điều này sẽ không gây hại cho doanh nghiệp chút nào, bởi vì chính bạn đã cùng nhau xác định điều này và bạn có không gian này không sử dụng nó. Bạn có ngân sách cho các lỗi mà trong trường hợp của bạn không được chi tiêu.
Chúng ta đang làm gì với nó? Chúng tôi sử dụng nó cho mọi thứ theo đúng nghĩa đen. Để thử nghiệm trong điều kiện sản xuất, để triển khai các tính năng mới có thể ảnh hưởng đến hiệu suất, để phát hành, để bảo trì, cho thời gian ngừng hoạt động theo kế hoạch. Quy tắc ngược lại cũng được áp dụng: nếu ngân sách cạn kiệt, chúng tôi không thể phát hành bất kỳ thứ gì mới, vì nếu không chúng tôi sẽ vượt quá SLO. Ngân sách đã cạn kiệt, chúng tôi đã phát hành thứ gì đó, nếu nó ảnh hưởng tiêu cực đến hiệu suất, nghĩa là, nếu bản thân nó không phải là một loại sửa chữa nào đó trực tiếp làm tăng SLO, thì chúng tôi đang vượt quá ngân sách và đây là một tình huống xấu , nó đòi hỏi phải phân tích, khám nghiệm tử thi và có thể sửa chữa một số quy trình.
Nghĩa là, hóa ra là nếu bản thân dịch vụ không hoạt động tốt và SLO được chi tiêu và ngân sách không được chi cho các thử nghiệm, không phải cho bất kỳ bản phát hành nào mà cho chính nó, thì thay vì một số bản sửa lỗi thú vị, thay vì thú vị các tính năng, thay vì các bản phát hành thú vị. Thay vì thực hiện bất kỳ công việc sáng tạo nào, bạn sẽ phải thực hiện những sửa chữa ngớ ngẩn để lấy lại ngân sách hoặc chỉnh sửa SLO và đây cũng là một quá trình không nên diễn ra quá thường xuyên.
Vì vậy, hóa ra là trong tình huống chúng ta có nhiều ngân sách hơn cho lỗi, mọi người đều quan tâm: cả SRE và nhà phát triển. Đối với các nhà phát triển, ngân sách lớn dành cho lỗi có nghĩa là họ có thể xử lý các bản phát hành, thử nghiệm và thử nghiệm. Đối với SRE, việc lập ngân sách dành cho sai sót và đưa vào ngân sách này có nghĩa là họ thực sự đang làm tốt công việc. Và điều này ảnh hưởng đến động lực của một số loại công việc chung. Nếu bạn lắng nghe SRE của mình với tư cách là nhà phát triển, bạn sẽ có nhiều cơ hội hơn để làm tốt công việc và ít việc nhà hơn.
Hóa ra các thử nghiệm trong sản xuất là một phần khá quan trọng và gần như không thể thiếu của SRE trong các nhóm lớn. Và nó thường được gọi là kỹ thuật hỗn loạn, xuất phát từ nhóm Netflix đã phát hành một tiện ích có tên Chaos Monkey.
Chaos Monkey kết nối với đường dẫn CI/CD và làm hỏng máy chủ một cách ngẫu nhiên trong quá trình sản xuất. Một lần nữa, trong cấu trúc SRE, chúng tôi nói rằng bản thân một máy chủ bị lỗi không phải là điều xấu, điều đó được mong đợi. Và nếu đưa vào ngân sách thì chấp nhận được và không gây tổn hại gì cho doanh nghiệp. Tất nhiên, Netflix có đủ máy chủ dự phòng, đủ bản sao, để tất cả những điều này có thể được khắc phục mà toàn bộ người dùng không hề nhận ra và chắc chắn không ai rời bỏ một máy chủ vì bất kỳ ngân sách nào.
Netflix đã có lúc có cả bộ tiện ích như vậy, một trong số đó, Chaos Gorilla, vô hiệu hóa hoàn toàn một trong các vùng khả dụng trên Amazon. Và những điều như vậy giúp ích rất nhiều cho việc xác định, trước hết, những sự phụ thuộc tiềm ẩn, khi không hoàn toàn rõ ràng điều gì ảnh hưởng đến điều gì, điều gì phụ thuộc vào điều gì. Và điều này, nếu bạn đang làm việc với một microservice và tài liệu không hoàn toàn hoàn hảo, điều này có thể quen thuộc với bạn. Và một lần nữa, điều này giúp bắt các lỗi trong code mà bạn không thể bắt được trong quá trình dàn dựng, bởi vì bất kỳ dàn dựng nào cũng không phải là mô phỏng chính xác, do thang tải khác nhau, kiểu tải khác nhau, thiết bị cũng vậy, hầu hết có thể, khác. Tải trọng cao điểm cũng có thể bất ngờ và không thể đoán trước. Và việc thử nghiệm như vậy, một lần nữa không vượt quá ngân sách, sẽ giúp phát hiện rất tốt các lỗi trong cơ sở hạ tầng mà các đường dẫn dàn dựng, tự động kiểm tra và CI/CD sẽ không bao giờ mắc phải. Và miễn là tất cả những thứ này đã được bao gồm trong ngân sách của bạn, thì việc dịch vụ của bạn bị giảm ở đó không thành vấn đề, mặc dù điều đó có vẻ rất đáng sợ, nhưng máy chủ đã gặp sự cố, quả là một cơn ác mộng. Không, điều đó bình thường, điều đó tốt, nó giúp bắt lỗi. Nếu bạn có ngân sách, bạn có thể chi tiêu nó.
Câu hỏi: Tôi có thể giới thiệu tài liệu nào? Danh sách ở cuối. Có rất nhiều tài liệu, tôi muốn giới thiệu một số báo cáo. Cách thức hoạt động và liệu SRE có hoạt động trong các công ty không có sản phẩm phần mềm của riêng họ hoặc có sự phát triển tối thiểu hay không. Ví dụ, trong một doanh nghiệp, hoạt động chính không phải là phần mềm. Trong một doanh nghiệp, nơi hoạt động chính không phải là phần mềm, SRE hoạt động giống hệt như bất kỳ nơi nào khác, bởi vì trong một doanh nghiệp bạn cũng cần sử dụng, ngay cả khi bạn không phát triển các sản phẩm phần mềm, bạn cần tung ra các bản cập nhật, bạn cần thay đổi cơ sở hạ tầng, bạn cần phát triển, bạn cần mở rộng quy mô. Và SRE giúp xác định và dự đoán các vấn đề có thể xảy ra trong các quy trình này và kiểm soát chúng sau khi bắt đầu tăng trưởng và nhu cầu kinh doanh thay đổi. Bởi vì hoàn toàn không cần thiết phải tham gia phát triển phần mềm để có SRE, nếu bạn có ít nhất một số máy chủ và bạn mong đợi ít nhất một số tăng trưởng.
Điều tương tự cũng xảy ra với các dự án nhỏ, tổ chức nhỏ, vì các công ty lớn có đủ ngân sách và không gian để thử nghiệm. Nhưng đồng thời, tất cả những thành quả thử nghiệm này có thể được sử dụng ở bất cứ đâu, tức là SRE tất nhiên đã xuất hiện trên Google, Netflix và Dropbox. Nhưng đồng thời, các công ty nhỏ và công ty khởi nghiệp đã có thể đọc tài liệu cô đọng, đọc sách và xem báo cáo. Họ bắt đầu nghe về điều này thường xuyên hơn, xem xét các ví dụ cụ thể, tôi nghĩ, được rồi, điều này thực sự có thể hữu ích, chúng ta cũng cần điều này, tuyệt.
Nghĩa là, tất cả công việc chính về tiêu chuẩn hóa các quy trình này đã được thực hiện cho bạn. Tất cả những gì bạn phải làm là xác định cụ thể vai trò của SRE trong công ty của mình và bắt đầu thực sự triển khai tất cả các phương pháp này, một lần nữa, đã được mô tả. Nghĩa là, từ những nguyên tắc hữu ích cho các công ty nhỏ, đây luôn là định nghĩa của SLA, SLI, SLO. Nếu bạn không tham gia vào phần mềm thì đây sẽ là SLA nội bộ và SLO nội bộ, ngân sách nội bộ dành cho lỗi. Điều này hầu như luôn dẫn đến một số cuộc thảo luận thú vị trong nhóm và trong doanh nghiệp, bởi vì có thể bạn đang chi tiêu nhiều hơn mức cần thiết cho cơ sở hạ tầng, cho một số loại tổ chức quy trình lý tưởng, một đường ống lý tưởng. Và 4 số XNUMX này mà bạn có trong bộ phận CNTT, bây giờ bạn không thực sự cần chúng. Nhưng đồng thời, có thể lãng phí thời gian, ngân sách cho những sai sót vào việc khác.
Theo đó, việc giám sát và tổ chức giám sát rất hữu ích cho một công ty ở mọi quy mô. Và nói chung, cách suy nghĩ này, nơi sai sót là điều có thể chấp nhận được, nơi có ngân sách, nơi tồn tại Mục tiêu, một lần nữa hữu ích cho một công ty thuộc mọi quy mô, bắt đầu từ công ty khởi nghiệp gồm 3 người.
Sắc thái kỹ thuật cuối cùng mà chúng ta có thể nói đến là giám sát. Bởi vì nếu nói về SLA, SLI, SLO, chúng ta không thể hiểu nếu không theo dõi xem liệu chúng ta có phù hợp với ngân sách hay không, liệu chúng ta có tuân thủ Mục tiêu của mình hay không và chúng ta ảnh hưởng đến SLA cuối cùng như thế nào. Tôi đã nhiều lần quan sát thấy việc giám sát diễn ra theo cách sau: có một số giá trị, chẳng hạn như thời gian yêu cầu đến máy chủ, thời gian trung bình hoặc số lượng yêu cầu tới cơ sở dữ liệu. Anh ta có một tiêu chuẩn được xác định bởi kỹ sư. Nếu số liệu lệch khỏi định mức, một email sẽ được gửi. Theo quy luật, điều này hoàn toàn vô ích vì nó dẫn đến sự quá bão hòa của các cảnh báo, sự quá bão hòa của các thông báo giám sát, khi một người, trước hết, phải giải thích chúng mọi lúc, nghĩa là xác định xem giá trị số liệu có nghĩa là cần thiết hay không. một số loại hành động. Và thứ hai, anh ta chỉ đơn giản là ngừng chú ý đến tất cả những cảnh báo này, khi về cơ bản anh ta không cần phải làm gì cả. Nghĩa là, một quy tắc giám sát tốt và quy tắc đầu tiên khi triển khai SRE là thông báo chỉ được đưa ra khi cần có một hành động.
Trong trường hợp tiêu chuẩn có 3 cấp độ sự kiện. Có cảnh báo, có vé, có nhật ký. Cảnh báo là bất cứ điều gì yêu cầu bạn phải hành động ngay lập tức. Tức là mọi thứ đều hỏng, cần phải sửa ngay. Vé là thứ đòi hỏi hành động đang chờ xử lý. Có, bạn cần phải làm điều gì đó, bạn cần phải làm điều gì đó một cách thủ công, quá trình tự động hóa đã thất bại, nhưng bạn không cần phải làm điều đó trong vài phút tới. Nhật ký là mọi thứ không cần phải hành động và nói chung, nếu mọi việc suôn sẻ thì sẽ không có ai đọc chúng. Chỉ cần đọc nhật ký khi nhìn lại, hóa ra có điều gì đó đã bị hỏng trong một thời gian mà chúng tôi không biết về nó. Hoặc một số loại điều tra cần phải được thực hiện. Nhưng nói chung, mọi thứ không yêu cầu bất kỳ hành động nào đều được ghi vào nhật ký.
Là một tác dụng phụ của tất cả những điều này, nếu chúng tôi đã xác định được sự kiện nào yêu cầu hành động và đã mô tả rõ ràng những hành động đó nên là gì thì điều này có nghĩa là hành động đó có thể được tự động hóa. Đó là, những gì sẽ xảy ra. Chúng tôi đang đến từ một cảnh báo. Hãy bắt tay vào hành động. Chúng ta hãy đi đến phần mô tả của hành động này. Và sau đó chúng tôi tiến tới tự động hóa. Nghĩa là, bất kỳ quá trình tự động hóa nào cũng bắt đầu bằng phản ứng trước một sự kiện.
Từ giám sát, chúng ta chuyển sang thuật ngữ gọi là Khả năng quan sát. Cũng có một chút cường điệu xung quanh từ này trong vài năm qua. Và ít người hiểu điều này có nghĩa là gì khi không nằm trong ngữ cảnh. Nhưng điểm chính là Khả năng quan sát là thước đo tính minh bạch của hệ thống. Nếu có sự cố xảy ra, bạn có thể nhanh chóng xác định chính xác điều gì đã xảy ra và trạng thái của hệ thống tại thời điểm đó. Từ quan điểm mã: chức năng nào bị lỗi, dịch vụ nào bị lỗi. Ví dụ, trạng thái của các biến nội bộ, cấu hình là gì. Từ quan điểm cơ sở hạ tầng, đây là vùng sẵn sàng xảy ra lỗi và nếu bạn có một số loại Kubernetes, thì lỗi xảy ra ở nhóm nào, trạng thái của nhóm là gì. Và theo đó, Observability có mối quan hệ trực tiếp với MTTR. Observability của dịch vụ càng cao thì càng dễ nhận diện lỗi, càng dễ sửa lỗi, càng dễ tự động hóa lỗi thì MTTR càng thấp.
Nếu chúng tôi chuyển sang các công ty nhỏ một lần nữa, ngay cả bây giờ họ vẫn thường hỏi phải làm gì với quy mô của nhóm và liệu có cần thiết phải thuê một SRE riêng trong một nhóm nhỏ hay không. Tôi đã nói về điều này sớm hơn một chút. Trong giai đoạn phát triển đầu tiên của một công ty khởi nghiệp hoặc một nhóm chẳng hạn, điều này hoàn toàn không cần thiết vì SRE có thể được coi là một vai trò chuyển tiếp. Và điều này sẽ làm sôi động đội lên một chút, vì ít nhất cũng có sự đa dạng nào đó. Và hơn nữa, nó sẽ giúp mọi người chuẩn bị cho thực tế rằng khi họ phát triển, nhìn chung, trách nhiệm của SRE sẽ thay đổi rất đáng kể. Nếu bạn thuê một người thì tất nhiên anh ta sẽ có một số kỳ vọng. Và những kỳ vọng này sẽ không thay đổi theo thời gian, nhưng yêu cầu sẽ thay đổi rất nhiều. Vì vậy, việc thuê SRE khá khó khăn trong giai đoạn đầu. Việc tự nuôi mình sẽ dễ dàng hơn nhiều. Nhưng nó đáng để suy nghĩ.
Có lẽ ngoại lệ duy nhất là khi có những yêu cầu về chiều cao rất nghiêm ngặt và được xác định rõ ràng. Nghĩa là, trong trường hợp khởi nghiệp, đây có thể là một loại áp lực nào đó từ các nhà đầu tư, một loại dự báo tăng trưởng nào đó nhiều lần cùng một lúc. Khi đó việc thuê một SRE nói chung là hợp lý vì nó có thể hợp lý. Chúng tôi có những yêu cầu về tăng trưởng, chúng tôi cần một người chịu trách nhiệm đảm bảo rằng không có gì phá vỡ sự tăng trưởng đó.
Một câu hỏi nữa. Phải làm gì khi nhiều lần nhà phát triển cắt một tính năng vượt qua thử nghiệm nhưng làm hỏng sản phẩm, tải cơ sở dữ liệu, phá vỡ các tính năng khác, phải thực hiện quy trình gì. Theo đó, trong trường hợp này, ngân sách dành cho lỗi được đưa ra. Và một số dịch vụ, một số tính năng được thử nghiệm ngay trong quá trình sản xuất. Đây có thể là một con chim hoàng yến, khi chỉ có một số lượng nhỏ người dùng, nhưng đã ở giai đoạn sản xuất, đang triển khai một tính năng, nhưng với kỳ vọng rằng nếu có điều gì đó xảy ra, chẳng hạn như đối với nửa phần trăm tổng số người dùng, tính năng đó vẫn sẽ phù hợp với ngân sách cho các lỗi. Theo đó, vâng, sẽ có lỗi, đối với một số người dùng, mọi thứ sẽ bị hỏng, nhưng chúng tôi đã nói rằng điều này là bình thường.
Có một câu hỏi về công cụ SRE. Nghĩa là, có điều gì cụ thể mà SRE sẽ sử dụng mà những người khác thì không? Trên thực tế, có một số tiện ích có tính chuyên môn cao, có một số phần mềm chẳng hạn như mô phỏng tải hoặc thực hiện thử nghiệm A/B kiểu canary. Nhưng về cơ bản, công cụ SRE là thứ mà các nhà phát triển của bạn đang sử dụng. Bởi vì SRE tương tác trực tiếp với nhóm phát triển. Và nếu bạn có các công cụ khác nhau, hóa ra sẽ cần có thời gian để đồng bộ hóa. Đặc biệt nếu SRE làm việc trong các nhóm lớn, trong các công ty lớn, nơi có thể có nhiều nhóm, thì việc tiêu chuẩn hóa toàn công ty ở đây sẽ rất hữu ích, vì nếu 50 nhóm sử dụng 50 tiện ích khác nhau, điều này có nghĩa là SRE phải biết tất cả. Và tất nhiên điều này sẽ không bao giờ xảy ra. Và chất lượng công việc, chất lượng kiểm soát của ít nhất một số đội sẽ giảm đi đáng kể.
Hội thảo trên web của chúng tôi đang dần đi đến hồi kết. Tôi đã cố gắng nói với bạn một số điều cơ bản. Tất nhiên, không có gì về SRE có thể được nói và hiểu trong một giờ. Nhưng tôi hy vọng rằng tôi đã truyền đạt được cách suy nghĩ này, những điểm chính. Và sau đó, nếu quan tâm, bạn có thể tìm hiểu sâu hơn về chủ đề này, tự nghiên cứu và xem nó đang được những người khác, ở các công ty khác triển khai như thế nào. Và theo đó, đầu tháng XNUMX hãy đến với chúng tôi tại Slurm SRE.
Slurm SRE là một khóa học chuyên sâu kéo dài ba ngày sẽ bao gồm những gì tôi đang nói bây giờ, nhưng có chiều sâu hơn nhiều, với các trường hợp thực tế, với thực hành, toàn bộ khóa học chuyên sâu đều nhằm vào công việc thực tế. Mọi người sẽ được chia thành các đội. Tất cả các bạn sẽ làm việc trên các trường hợp thực tế. Theo đó, chúng tôi có những người hướng dẫn từ Booking.com Ivan Kruglov và Ben Tyler. Chúng tôi có một Evgeniy Varabbas tuyệt vời từ Google, đến từ San Francisco. Và tôi cũng sẽ nói với bạn điều gì đó. Vì vậy hãy chắc chắn đến thăm chúng tôi.
Vì vậy, một danh sách các tài liệu tham khảo. Có liên kết trên SRE. trên cùng cuốn sách đó, hay đúng hơn là trên 2 cuốn sách về SRE, do Google viết. Một cái khác , trong đó các điều khoản và ứng dụng của chúng được giải thích chi tiết hơn một chút. 3 báo cáo tiếp theo là về SRE ở các công ty khác nhau. Đầu tiên - , đây là bài phát biểu quan trọng của Ben Trainer từ Google. Thứ hai - . Thứ ba lại là về . Báo cáo thứ tư từ , chỉ có 5 nhân viên chủ chốt của SRE ở 190 quốc gia. Thật thú vị khi xem xét tất cả những điều này, bởi vì DevOps có ý nghĩa rất khác nhau đối với các công ty khác nhau và thậm chí cả các nhóm khác nhau, SRE có những trách nhiệm rất khác nhau, ngay cả ở các công ty có quy mô tương tự.
Thêm 2 liên kết về nguyên tắc kỹ thuật hỗn loạn: , . Và cuối cùng có 3 danh sách thuộc chuỗi Danh sách tuyệt vời về về và về . Danh sách trên SRE cực kỳ lớn, bạn không cần phải xem hết, có khoảng 200 bài viết. Tôi đặc biệt giới thiệu các bài viết về lập kế hoạch năng lực và khám nghiệm tử thi vô tội.
Bài viết thú vị:
Cảm ơn bạn đã lắng nghe tôi suốt thời gian qua. Tôi hy vọng bạn đã học được điều gì đó. Tôi hy vọng bạn có đủ tài liệu để học hỏi nhiều hơn nữa. Và hẹn gặp lại sau. Hy vọng vào tháng Hai.
Hội thảo trực tuyến được tổ chức bởi Eduard Medvedev.
Tái bút: dành cho những ai thích đọc sách, Eduard cung cấp danh sách tài liệu tham khảo. Những ai muốn hiểu nó trong thực tế đều được chào đón tại .
Nguồn: www.habr.com