Công ty chúng tôi đang trong quá trình thành lập nhóm SRE. Tôi xem toàn bộ câu chuyện này từ phía phát triển. Trong quá trình này, tôi đã nảy ra những suy nghĩ và hiểu biết sâu sắc mà tôi muốn chia sẻ với các nhà phát triển khác. Trong bài viết phản ánh này, tôi nói về những gì đang xảy ra, nó đang diễn ra như thế nào và làm thế nào mọi người có thể tiếp tục chung sống với nó.
Tiếp nối loạt bài viết dựa trên các bài phát biểu tại sự kiện nội bộ của chúng tôi :
2. Cơ sở hạ tầng dưới dạng mã. (Bạn đang ở đây)
3. Tạo hợp đồng Typescript bằng mô hình C#. (Trong tiến trình...)
4. Giới thiệu thuật toán đồng thuận Raft. (Trong tiến trình...)
...
Chúng tôi quyết định thành lập nhóm SRE, thực hiện các ý tưởng . Họ tuyển dụng các lập trình viên từ chính các nhà phát triển của họ và cử họ đi đào tạo trong vài tháng.
Nhóm đã có các nhiệm vụ đào tạo sau:
- Mô tả cơ sở hạ tầng của chúng tôi, chủ yếu có trong Microsoft Azure dưới dạng mã (Terraform và mọi thứ xung quanh).
- Dạy các nhà phát triển cách làm việc với cơ sở hạ tầng.
- Chuẩn bị cho các nhà phát triển thực hiện nhiệm vụ.
Chúng tôi giới thiệu khái niệm Cơ sở hạ tầng dưới dạng mã
Trong mô hình thông thường của thế giới (hành chính cổ điển), kiến thức về cơ sở hạ tầng nằm ở hai nơi:
- Hoặc dưới dạng kiến thức trong đầu của các chuyên gia.
- Hoặc thông tin này có trên một số máy đánh chữ, một số được các chuyên gia biết đến. Nhưng thực tế không phải là một người ngoài cuộc (trong trường hợp toàn bộ nhóm của chúng tôi đột ngột qua đời) sẽ có thể tìm ra cách hoạt động và cách thức hoạt động. Có thể có rất nhiều thông tin trên một máy: phụ kiện, cronjob, hăm dọa (xem. ) và chỉ là một danh sách vô tận những gì có thể xảy ra. Thật khó để hiểu những gì đang thực sự xảy ra.
Trong cả hai trường hợp, chúng ta thấy mình bị mắc kẹt trong việc trở nên phụ thuộc:
- hoặc từ một người phàm trần, bị bệnh tật, đang yêu, tâm trạng thất thường và đơn giản là bị sa thải tầm thường;
- hoặc từ một cỗ máy hoạt động vật lý, cũng bị rơi, bị đánh cắp và gây ra những bất ngờ và bất tiện.
Không cần phải nói rằng lý tưởng nhất là mọi thứ nên được dịch sang mã dễ đọc, dễ bảo trì và được viết tốt.
Do đó, cơ sở hạ tầng dưới dạng mã (Incfastructure as Code - IaC) là mô tả về toàn bộ cơ sở hạ tầng hiện có dưới dạng mã, cũng như các công cụ liên quan để làm việc với nó và triển khai cơ sở hạ tầng thực sự từ nó.
Tại sao dịch mọi thứ thành mã?Con người không phải là máy móc. Họ không thể nhớ tất cả mọi thứ. Phản ứng của con người và máy móc là khác nhau. Bất cứ điều gì được tự động hóa đều có khả năng nhanh hơn bất cứ điều gì được thực hiện bởi con người. Điều quan trọng nhất là một nguồn sự thật duy nhất.
Các kỹ sư SRE mới đến từ đâu?Vì vậy, chúng tôi quyết định thuê các kỹ sư SRE mới, nhưng tìm họ từ đâu? Sách có câu trả lời đúng () cho chúng ta biết: từ các nhà phát triển. Rốt cuộc, chúng hoạt động với mã và bạn đạt được trạng thái lý tưởng.
Chúng tôi đã tìm kiếm họ rất lâu trên thị trường nhân sự bên ngoài công ty chúng tôi. Nhưng chúng tôi phải thừa nhận rằng chúng tôi không tìm thấy ai phù hợp với yêu cầu của mình. Tôi phải tìm kiếm giữa những người của mình.
Sự cố Cơ sở hạ tầng dưới dạng mã
Bây giờ hãy xem các ví dụ về cách mã hóa cơ sở hạ tầng thành mã. Mã được viết tốt, chất lượng cao, có nhận xét và thụt lề.
Mã ví dụ từ Terraforma.
Mã ví dụ từ Ansible.
Thưa quý vị, giá như nó đơn giản như vậy! Chúng ta đang ở trong thế giới thực, và nó luôn sẵn sàng làm bạn ngạc nhiên, mang đến cho bạn những bất ngờ và vấn đề. Không thể làm gì nếu không có họ ở đây.
1. Vấn đề đầu tiên là trong hầu hết các trường hợp, IaC là một loại dsl.
Và DSL, đến lượt nó, là một mô tả về cấu trúc. Chính xác hơn, những gì bạn nên có: Json, Yaml, các bản sửa đổi từ một số công ty lớn đã đưa ra dsl của riêng họ (HCL được sử dụng ở dạng terraform).
Vấn đề là nó có thể dễ dàng không chứa những thứ quen thuộc như:
- biến;
- điều kiện;
- ở đâu đó không có nhận xét nào, chẳng hạn như trong Json, theo mặc định chúng không được cung cấp;
- chức năng;
- và tôi thậm chí không nói về những thứ cấp cao như lớp học, sự kế thừa và tất cả những thứ đó.
2. Vấn đề thứ hai với mã như vậy thường là nó là một môi trường không đồng nhất. Thông thường bạn ngồi và làm việc với C#, tức là. với một ngôn ngữ, một ngăn xếp, một hệ sinh thái. Và ở đây bạn có rất nhiều công nghệ.
Đó là một tình huống rất thực tế khi bash với python khởi chạy một số quy trình mà Json được chèn vào. Bạn phân tích nó, sau đó một số trình tạo khác sẽ tạo ra 30 tệp khác. Đối với tất cả những điều này, các biến đầu vào được nhận từ Azure Key Vault, được tập hợp lại bằng một plugin dành cho drone.io được viết bằng Go và các biến này chuyển qua yaml, được tạo ra từ quá trình tạo từ công cụ mẫu jsonnet. Rất khó để có mã được mô tả chính xác khi bạn có môi trường đa dạng như vậy.
Sự phát triển truyền thống trong khuôn khổ một nhiệm vụ đi kèm với một ngôn ngữ. Ở đây chúng tôi làm việc với một số lượng lớn các ngôn ngữ.
3. Vấn đề thứ ba là điều chỉnh. Chúng tôi đã quen với những biên tập viên tuyệt vời (Ms Visual Studio, Jetbrains Rider), những người làm mọi thứ cho chúng tôi. Và ngay cả khi chúng ta ngu ngốc, họ sẽ nói rằng chúng ta sai. Nó có vẻ bình thường và tự nhiên.
Nhưng ở đâu đó gần đó có VSCode, trong đó có một số plugin được cài đặt, hỗ trợ hoặc không được hỗ trợ bằng cách nào đó. Các phiên bản mới xuất hiện và không được hỗ trợ. Quá trình chuyển đổi tầm thường sang thực hiện một chức năng (ngay cả khi nó tồn tại) trở thành một vấn đề phức tạp và không hề tầm thường. Việc đổi tên đơn giản một biến là phát lại trong một dự án gồm hàng tá tệp. Bạn sẽ may mắn nếu anh ấy đặt những gì bạn cần. Tất nhiên, ở đây có đèn nền, có tính năng tự động hoàn thành, ở đâu đó có định dạng (mặc dù nó không hoạt động đối với tôi ở dạng terraform trên Windows).
Tại thời điểm viết bài này vẫn chưa được phát hành để hỗ trợ phiên bản 0.12, mặc dù nó đã được phát hành được 3 tháng.
Đã đến lúc phải quên đi...
- Gỡ lỗi.
- Công cụ tái cấu trúc.
- Tự động hoàn thành.
- Phát hiện lỗi trong quá trình biên dịch.
Thật buồn cười, nhưng điều này cũng làm tăng thời gian phát triển và tăng số lượng lỗi chắc chắn xảy ra.
Điều tồi tệ nhất là chúng ta buộc phải nghĩ không phải về cách thiết kế, sắp xếp các tệp thành các thư mục, phân tách, làm cho mã có thể bảo trì, dễ đọc, v.v. mà là về cách tôi có thể viết lệnh này một cách chính xác, bởi vì bằng cách nào đó tôi đã viết sai. .
Là người mới bắt đầu, bạn đang cố gắng tìm hiểu các địa hình và IDE hoàn toàn không giúp ích gì cho bạn. Khi nào có tài liệu thì vào xem. Nhưng nếu bạn đang nhập một ngôn ngữ lập trình mới, IDE sẽ cho bạn biết rằng có loại như vậy, nhưng không có thứ như vậy. Ít nhất là ở cấp độ int hoặc chuỗi. Điều này thường hữu ích.
Còn các bài kiểm tra thì sao?
Bạn hỏi: “Còn các bài kiểm tra thì sao, thưa các lập trình viên?” Những người nghiêm túc kiểm tra mọi thứ trong quá trình sản xuất và điều đó thật khó khăn. Dưới đây là ví dụ về thử nghiệm đơn vị cho mô-đun địa hình từ trang web .
Họ có tài liệu tốt. Tôi luôn thích Microsoft vì cách tiếp cận tài liệu và đào tạo. Nhưng bạn không cần phải là chú Bob mới hiểu rằng đây không phải là đoạn mã hoàn hảo. Lưu ý xác nhận ở bên phải.
Vấn đề với bài kiểm tra đơn vị là bạn và tôi có thể kiểm tra tính chính xác của đầu ra Json. Tôi đưa vào 5 thông số và được tặng một chiếc khăn lau chân Json với 2000 dòng. Tôi có thể phân tích những gì đang diễn ra ở đây, xác nhận kết quả kiểm tra...
Thật khó để phân tích Json trong Go. Và bạn cần phải viết bằng Go, vì terraform trong Go là một phương pháp hay để thử nghiệm bằng ngôn ngữ mà bạn viết. Bản thân việc tổ chức mã rất yếu. Đồng thời, đây là thư viện tốt nhất để thử nghiệm.
Bản thân Microsoft viết các mô-đun của mình và kiểm tra chúng theo cách này. Tất nhiên đó là Nguồn mở. Mọi điều tôi đang nói, bạn có thể đến và sửa chữa. Tôi có thể ngồi xuống và sửa mọi thứ trong một tuần, các plugin mã nguồn mở VS, terraforms, tạo một plugin cho người lái. Có thể viết một vài máy phân tích, thêm linters, đóng góp một thư viện để thử nghiệm. Tôi có thể làm mọi thứ. Nhưng đó không phải điều tôi nên làm.
Các phương pháp hay nhất Cơ sở hạ tầng dưới dạng mã
Tiếp tục nào. Nếu không có thử nghiệm nào trong IaC, IDE và khả năng điều chỉnh kém thì ít nhất phải có các phương pháp hay nhất. Tôi vừa truy cập Google Analytics và so sánh hai truy vấn tìm kiếm: các phương pháp hay nhất về Terraform và các phương pháp hay nhất về C#.
Chúng ta thấy gì? Số liệu thống kê tàn nhẫn không có lợi cho chúng tôi. Lượng vật liệu là như nhau. Trong quá trình phát triển C#, chúng tôi chỉ đơn giản là có rất nhiều tài liệu, chúng tôi có những phương pháp thực hành siêu tốt nhất, có những cuốn sách được viết bởi các chuyên gia và cũng có những cuốn sách được viết trên sách của các chuyên gia khác chỉ trích những cuốn sách đó. Một biển tài liệu, bài báo, khóa đào tạo chính thức và giờ đây còn có cả sự phát triển nguồn mở.
Đối với yêu cầu IaC: ở đây bạn đang cố gắng thu thập thông tin từng chút một từ các báo cáo tải trọng cao hoặc HashiConf, từ tài liệu chính thức và nhiều vấn đề trên Github. Làm thế nào để phân phối các mô-đun này nói chung, phải làm gì với chúng? Có vẻ như đây là một vấn đề thực sự... Có một cộng đồng, thưa các quý ông, nơi đối với bất kỳ câu hỏi nào, bạn sẽ nhận được 10 bình luận trên Github. Nhưng nó không chính xác.
Thật không may, tại thời điểm này, các chuyên gia mới bắt đầu xuất hiện. Có quá ít trong số họ cho đến nay. Và bản thân cộng đồng này đang ở mức độ thô sơ.
Tất cả chuyện này sẽ đi đến đâu và phải làm gì
Bạn có thể bỏ mọi thứ và quay lại C#, trở lại thế giới của người lái. Nhưng không. Tại sao bạn lại bận tâm làm điều này nếu bạn không thể tìm ra giải pháp. Dưới đây tôi trình bày kết luận chủ quan của tôi. Bạn có thể tranh luận với tôi trong phần bình luận, nó sẽ rất thú vị.
Cá nhân tôi đang đặt cược vào một số điều:
- Sự phát triển trong lĩnh vực này đang diễn ra rất nhanh chóng. Dưới đây là lịch trình yêu cầu dành cho DevOps.
Chủ đề có thể là cường điệu hóa, nhưng thực tế là quả cầu đang phát triển mang lại chút hy vọng.Nếu thứ gì đó phát triển nhanh chóng như vậy thì chắc chắn sẽ xuất hiện những người thông minh, người sẽ bảo bạn phải làm gì và không nên làm gì. Sự phổ biến ngày càng tăng dẫn đến thực tế là có thể ai đó sẽ có thời gian để thêm một plugin vào jsonnet cho vscode, điều này sẽ cho phép bạn chuyển sang triển khai chức năng thay vì tìm kiếm nó thông qua ctrl+shift+f. Khi mọi thứ phát triển, nhiều vật liệu hơn xuất hiện. Việc phát hành một cuốn sách của Google về SRE là một ví dụ điển hình về điều này.
- Có những kỹ thuật và thực tiễn đã được phát triển trong quá trình phát triển thông thường mà chúng tôi có thể áp dụng thành công ở đây. Đúng, có những sắc thái khác nhau trong quá trình thử nghiệm và môi trường không đồng nhất, công cụ không đầy đủ, nhưng một số lượng lớn các phương pháp thực hành đã được tích lũy có thể hữu ích và hữu ích.
Một ví dụ tầm thường: cộng tác thông qua lập trình cặp. Nó giúp ích rất nhiều để tìm ra nó. Khi bạn có một người hàng xóm ở gần cũng đang cố gắng hiểu điều gì đó, bạn sẽ cùng nhau hiểu rõ hơn.
Hiểu cách thực hiện tái cấu trúc sẽ giúp thực hiện nó ngay cả trong tình huống như vậy. Tức là bạn không thể thay đổi mọi thứ cùng một lúc mà thay đổi cách đặt tên, sau đó thay đổi vị trí, sau đó bạn có thể đánh dấu một phần nào đó, ồ, nhưng ở đây không có đủ bình luận.
Kết luận
Mặc dù lý do của tôi có vẻ bi quan, nhưng tôi nhìn về tương lai với niềm hy vọng và chân thành hy vọng rằng mọi việc sẽ ổn thỏa với chúng tôi (và bạn).
Phần thứ hai của bài viết đang được chuẩn bị tiếp theo. Trong đó, tôi sẽ nói về cách chúng tôi cố gắng sử dụng các phương pháp phát triển linh hoạt để cải thiện quá trình học tập và làm việc với cơ sở hạ tầng.
Nguồn: www.habr.com