Xin chào, Habr! Trước đây, tôi đã phàn nàn về cuộc sống trong Cơ sở hạ tầng dưới dạng mô hình mã và không đưa ra bất cứ điều gì để giải quyết tình hình hiện tại. Hôm nay tôi quay lại để cho bạn biết những cách tiếp cận và thực hành nào sẽ giúp bạn thoát khỏi vực thẳm tuyệt vọng và đưa tình hình đi đúng hướng.
Trong một bài viết trước Tôi đã chia sẻ ấn tượng của mình về lĩnh vực này, cố gắng suy ngẫm về tình hình hiện tại trong lĩnh vực này và thậm chí còn đề xuất rằng các phương pháp tiêu chuẩn mà tất cả các nhà phát triển đều biết có thể hữu ích. Có vẻ như có rất nhiều lời phàn nàn về cuộc sống nhưng lại không có đề xuất nào để thoát khỏi tình trạng hiện tại.
Chúng tôi là ai, chúng tôi ở đâu và chúng tôi gặp phải vấn đề gì
Chúng tôi hiện đang ở trong Nhóm giới thiệu Sre, bao gồm sáu lập trình viên và ba kỹ sư cơ sở hạ tầng. Tất cả chúng ta đều đang cố gắng viết Cơ sở hạ tầng dưới dạng mã (IaC). Chúng tôi làm điều này vì về cơ bản chúng tôi biết cách viết mã và có lịch sử là nhà phát triển “trên mức trung bình”.
- Chúng tôi có nhiều lợi thế: nền tảng kiến thức nhất định, kiến thức thực tiễn, khả năng viết mã, mong muốn học hỏi những điều mới.
- Và có một phần chùng xuống, cũng là điểm trừ: thiếu hiểu biết về phần cứng hạ tầng.
Nhóm công nghệ chúng tôi sử dụng trong IaC của mình.
- Terraform để tạo tài nguyên.
- Packer để lắp ráp hình ảnh. Đây là hình ảnh Windows, CentOS 7.
- Jsonnet để tạo bản dựng mạnh mẽ trong drone.io, cũng như tạo json trình đóng gói và các mô-đun địa hình của chúng tôi.
- xanh.
- Ansible khi chuẩn bị hình ảnh.
- Python cho các dịch vụ phụ trợ và tập lệnh cung cấp.
- Và tất cả điều này có trong VSCode với các plugin được chia sẻ giữa các thành viên trong nhóm.
Kết luận từ tôi là như thế này: Tôi đã cố gắng truyền cho (trước hết là vào bản thân mình) sự lạc quan, tôi muốn nói rằng chúng tôi sẽ thử các cách tiếp cận và thực tiễn mà chúng tôi đã biết để giải quyết những khó khăn và phức tạp tồn tại trong lĩnh vực này.
Chúng tôi hiện đang gặp khó khăn với các vấn đề IaC sau:
- Sự không hoàn hảo của các công cụ và phương tiện để phát triển mã.
- Triển khai chậm. Cơ sở hạ tầng là một phần của thế giới thực và nó có thể hoạt động chậm.
- Thiếu phương pháp tiếp cận và thực hành.
- Chúng tôi là người mới và không biết nhiều.
Lập trình cực đoan (XP) để giải cứu
Tất cả các nhà phát triển đều quen thuộc với Lập trình cực đoan (XP) và các phương pháp thực hành đằng sau nó. Nhiều người trong chúng tôi đã làm việc với phương pháp này và đã thành công. Vậy tại sao không sử dụng các nguyên tắc và thực tiễn được đặt ra ở đó để vượt qua những thách thức về cơ sở hạ tầng? Chúng tôi quyết định thực hiện phương pháp này và xem điều gì sẽ xảy ra.
Kiểm tra khả năng áp dụng phương pháp XP vào ngành của bạnDưới đây là mô tả về môi trường mà XP rất phù hợp và nó liên quan như thế nào đến chúng ta:
1. Yêu cầu phần mềm thay đổi linh hoạt. Chúng tôi đã rõ mục tiêu cuối cùng là gì. Nhưng các chi tiết có thể khác nhau. Chính chúng tôi quyết định nơi chúng tôi cần taxi, vì vậy các yêu cầu thay đổi định kỳ (chủ yếu là do chính chúng tôi). Nếu chúng ta lấy nhóm SRE, nhóm tự động hóa và tự giới hạn các yêu cầu cũng như phạm vi công việc, thì điểm này rất phù hợp.
2. Rủi ro do dự án có thời gian cố định sử dụng công nghệ mới. Chúng ta có thể gặp rủi ro khi sử dụng một số thứ mà chúng ta chưa biết. Và đây là trường hợp của chúng tôi 100%. Toàn bộ dự án của chúng tôi là sử dụng những công nghệ mà chúng tôi chưa hoàn toàn quen thuộc. Nói chung, đây là một vấn đề thường xuyên, bởi vì... Luôn có nhiều công nghệ mới đang nổi lên trong lĩnh vực cơ sở hạ tầng.
3,4. Nhóm phát triển mở rộng nhỏ, cùng địa điểm. Công nghệ tự động mà bạn đang sử dụng cho phép thực hiện các bài kiểm tra đơn vị và chức năng. Hai điểm này không hoàn toàn phù hợp với chúng tôi. Thứ nhất, chúng tôi không phải là một đội phối hợp, thứ hai, chúng tôi có 14 người, có thể coi là một đội lớn. Mặc dù, theo một số định nghĩa về một nhóm “lớn”, có rất nhiều người trên XNUMX tuổi.
Hãy xem xét một số cách thực hành của XP và cách chúng ảnh hưởng đến tốc độ cũng như chất lượng phản hồi.
Nguyên tắc vòng phản hồi XP
Theo hiểu biết của tôi, phản hồi là câu trả lời cho câu hỏi, tôi có đang làm đúng không, chúng ta có đến đó không? XP có một kế hoạch thần thánh cho việc này: một vòng phản hồi thời gian. Điều thú vị là chúng ta càng ở mức thấp thì hệ điều hành càng có khả năng trả lời các câu hỏi cần thiết nhanh hơn.
Đây là một chủ đề khá thú vị để thảo luận, đó là trong ngành CNTT của chúng ta có thể nhanh chóng có được một hệ điều hành. Hãy tưởng tượng bạn sẽ đau đớn thế nào khi thực hiện một dự án trong sáu tháng và chỉ sau đó mới phát hiện ra rằng đã có sai sót ngay từ đầu. Điều này xảy ra trong thiết kế và trong bất kỳ việc xây dựng hệ thống phức tạp nào.
Trong trường hợp IaC của chúng tôi, phản hồi sẽ giúp ích cho chúng tôi. Tôi sẽ ngay lập tức thực hiện một điều chỉnh nhỏ đối với sơ đồ trên: kế hoạch phát hành không có chu kỳ hàng tháng mà diễn ra nhiều lần trong ngày. Có một số thực tiễn gắn liền với chu trình hệ điều hành này mà chúng ta sẽ xem xét chi tiết hơn.
Quan trọng: phản hồi có thể là giải pháp cho tất cả các vấn đề nêu trên. Kết hợp với các bài thực hành XP, nó có thể kéo bạn ra khỏi vực thẳm tuyệt vọng.
Làm thế nào để kéo mình ra khỏi vực thẳm tuyệt vọng: ba cách thực hành
Kiểm tra
Các thử nghiệm được đề cập hai lần trong vòng phản hồi XP. Nó không chỉ như vậy. Chúng cực kỳ quan trọng đối với toàn bộ kỹ thuật Lập trình Cực đoan.
Giả định rằng bạn có bài kiểm tra Đơn vị và Chấp nhận. Một số cung cấp cho bạn phản hồi trong vài phút, một số khác trong vài ngày, vì vậy họ mất nhiều thời gian hơn để viết và ít được xem xét thường xuyên hơn.
Có một kim tự tháp thử nghiệm cổ điển cho thấy cần phải có nhiều thử nghiệm hơn.
Khung này áp dụng cho chúng ta như thế nào trong dự án IaC? Thực ra... không hề.
- Các bài kiểm tra đơn vị, mặc dù thực tế là phải có rất nhiều nhưng không thể quá nhiều. Hoặc họ đang thử nghiệm điều gì đó một cách gián tiếp. Trên thực tế, chúng ta có thể nói rằng chúng ta không hề viết chúng. Nhưng đây là một số ứng dụng cho các thử nghiệm như vậy mà chúng tôi có thể thực hiện:
- Kiểm tra mã jsonnet. Ví dụ, đây là quy trình lắp ráp máy bay không người lái của chúng tôi, khá phức tạp. Mã jsonnet được kiểm tra tốt.
Chúng tôi sử dụng cái này . - Kiểm tra các tập lệnh được thực thi khi tài nguyên khởi động. Các tập lệnh được viết bằng Python và do đó các bài kiểm tra có thể được viết trên chúng.
- Kiểm tra mã jsonnet. Ví dụ, đây là quy trình lắp ráp máy bay không người lái của chúng tôi, khá phức tạp. Mã jsonnet được kiểm tra tốt.
- Có khả năng có thể kiểm tra cấu hình trong các thử nghiệm, nhưng chúng tôi không làm điều đó. Cũng có thể định cấu hình kiểm tra quy tắc cấu hình tài nguyên thông qua . Tuy nhiên, các bước kiểm tra ở đó đơn giản là quá cơ bản đối với terraform, nhưng nhiều tập lệnh kiểm tra được viết cho AWS. Và chúng tôi đang sử dụng Azure nên điều này lại không áp dụng.
- Kiểm tra tích hợp thành phần: nó phụ thuộc vào cách bạn phân loại chúng và nơi bạn đặt chúng. Nhưng về cơ bản chúng có tác dụng.
Đây là những gì các bài kiểm tra tích hợp trông như thế này.
Đây là một ví dụ khi xây dựng hình ảnh trong Drone CI. Để tiếp cận họ, bạn phải đợi 30 phút để hình ảnh Packer hình thành, sau đó đợi thêm 15 phút nữa để họ đi qua. Nhưng chúng tồn tại!Thuật toán xác minh hình ảnh
- Packer trước tiên phải chuẩn bị hình ảnh một cách đầy đủ.
- Bên cạnh thử nghiệm có một địa hình với trạng thái cục bộ mà chúng tôi sử dụng để triển khai hình ảnh này.
- Khi mở ra, một mô-đun nhỏ nằm gần đó sẽ được sử dụng để giúp thao tác với hình ảnh dễ dàng hơn.
- Sau khi VM được triển khai từ image, quá trình kiểm tra có thể bắt đầu. Về cơ bản, việc kiểm tra được thực hiện bằng ô tô. Nó kiểm tra cách các tập lệnh hoạt động khi khởi động và cách hoạt động của các trình tiện ích. Để thực hiện việc này, thông qua ssh hoặc winrm chúng ta đăng nhập vào máy mới nâng lên và kiểm tra trạng thái cấu hình hoặc các dịch vụ có hoạt động hay không.
- Tình huống tương tự với các thử nghiệm tích hợp trong mô-đun dành cho địa hình. Đây là một bảng ngắn giải thích các tính năng của các bài kiểm tra như vậy.
Phản hồi về đường ống là khoảng 40 phút. Mọi thứ xảy ra trong một thời gian rất dài. Nó có thể được sử dụng để hồi quy, nhưng đối với sự phát triển mới, nó thường không thực tế. Nếu bạn đã chuẩn bị rất kỹ cho việc này, hãy chuẩn bị các tập lệnh đang chạy, thì bạn có thể giảm thời gian xuống còn 10 phút. Nhưng đây vẫn không phải là bài kiểm tra Đơn vị, thực hiện 5 phần trong 100 giây.
Việc thiếu các bài kiểm tra Đơn vị khi tập hợp các hình ảnh hoặc mô-đun địa hình khuyến khích chuyển công việc sang các dịch vụ riêng biệt có thể chạy đơn giản thông qua REST hoặc sang các tập lệnh Python.
Ví dụ: chúng tôi cần đảm bảo rằng khi máy ảo khởi động, nó sẽ tự đăng ký trong dịch vụ , và khi máy ảo bị phá hủy, nó sẽ tự xóa chính nó.
Vì chúng tôi có dịch vụ ScalFT nên chúng tôi buộc phải làm việc với nó thông qua API. Có một cái giấy gói được viết ở đó mà bạn có thể kéo ra và nói: “Vào và xóa cái này cái kia đi.” Nó lưu trữ tất cả các cài đặt và quyền truy cập cần thiết.
Chúng tôi đã có thể viết các bài kiểm tra bình thường cho phần mềm này, vì nó không khác gì phần mềm thông thường: một loại apiha nào đó bị chế nhạo, bạn kéo nó ra và xem điều gì sẽ xảy ra.
Kết quả của các cuộc kiểm tra: Thử nghiệm đơn vị, sẽ cung cấp cho hệ điều hành trong một phút, lại không cung cấp cho hệ điều hành đó. Và các loại thử nghiệm cao hơn trong kim tự tháp cũng có hiệu quả nhưng chỉ giải quyết được một phần vấn đề.
Lập trình cặp
Tất nhiên, các bài kiểm tra đều tốt. Bạn có thể viết rất nhiều trong số chúng, chúng có thể thuộc nhiều loại khác nhau. Họ sẽ làm việc ở cấp độ của họ và đưa ra phản hồi cho chúng tôi. Nhưng vấn đề với các bài kiểm tra Đơn vị kém, mang lại hệ điều hành nhanh nhất, vẫn còn. Đồng thời, tôi vẫn muốn có một hệ điều hành nhanh, dễ sử dụng và thú vị. Chưa kể đến chất lượng của giải pháp thu được. May mắn thay, có những kỹ thuật có thể cung cấp phản hồi nhanh hơn cả bài kiểm tra đơn vị. Đây là lập trình cặp.
Khi viết mã, bạn muốn nhận được phản hồi về chất lượng của nó càng nhanh càng tốt. Có, bạn có thể viết mọi thứ trong một nhánh tính năng (để không làm hỏng bất kỳ thứ gì đối với bất kỳ ai), thực hiện yêu cầu kéo trong Github, giao nó cho người có ý kiến có trọng lượng và chờ phản hồi.
Nhưng bạn có thể đợi lâu. Mọi người đều bận rộn và câu trả lời, ngay cả khi có, cũng có thể không có chất lượng cao nhất. Giả sử câu trả lời đến ngay lập tức, người nhận xét hiểu ngay toàn bộ ý nhưng câu trả lời vẫn đến muộn, sau sự việc đã xảy ra. Tôi ước nó sớm hơn. Đây chính là mục tiêu mà chương trình cặp hướng tới – ngay lập tức, tại thời điểm viết bài.
Dưới đây là các kiểu lập trình cặp và khả năng ứng dụng của chúng khi làm việc trên IaC:
1. Cổ điển, Có kinh nghiệm+Có kinh nghiệm, chuyển đổi theo hẹn giờ. Hai vai trò – người lái và hoa tiêu. Hai người. Họ làm việc trên cùng một mã và chuyển đổi vai trò sau một khoảng thời gian định trước nhất định.
Hãy xem xét tính tương thích của các vấn đề của chúng tôi với phong cách:
- Vấn đề: sự không hoàn hảo của các công cụ và công cụ để phát triển mã.
Tác động tiêu cực: phát triển lâu hơn, chúng ta chậm lại, mất nhịp độ/nhịp điệu công việc.
Cách chúng tôi chiến đấu: chúng tôi sử dụng một công cụ khác, một IDE chung và cũng tìm hiểu các lối tắt. - Vấn đề: Triển khai chậm.
Tác động tiêu cực: tăng thời gian cần thiết để tạo một đoạn mã hoạt động. Chúng ta cảm thấy nhàm chán khi chờ đợi, tay chúng ta vươn ra để làm việc khác trong khi chờ đợi.
Cách chúng tôi chiến đấu: chúng tôi đã không vượt qua được nó. - Vấn đề: thiếu phương pháp tiếp cận và thực hành.
Tác động tiêu cực: không có kiến thức về cách làm tốt và cách làm kém. Kéo dài thời gian nhận phản hồi.
Cách chúng ta đấu tranh: việc trao đổi quan điểm và thực hành lẫn nhau khi làm việc theo cặp gần như giải quyết được vấn đề.
Vấn đề chính khi sử dụng phong cách này trong IaC là tốc độ làm việc không đồng đều. Trong phát triển phần mềm truyền thống, bạn có một phong trào rất thống nhất. Bạn có thể dành năm phút và viết N. Dành 10 phút và viết 2N, 15 phút - 3N. Ở đây bạn có thể dành năm phút để viết N, sau đó dành 30 phút nữa để viết một phần mười N. Ở đây bạn không biết gì cả, bạn bế tắc, ngu ngốc. Cuộc điều tra mất thời gian và làm mất tập trung vào việc lập trình.
Kết luận: ở dạng nguyên chất, nó không phù hợp với chúng ta.
2. Bóng bàn. Cách tiếp cận này bao gồm một người viết bài kiểm tra và một người khác thực hiện nó. Tính đến thực tế là mọi thứ đều phức tạp với các bài kiểm tra Đơn vị và bạn phải viết một bài kiểm tra tích hợp mất nhiều thời gian để lập trình, tất cả sự dễ dàng của bóng bàn sẽ biến mất.
Tôi có thể nói rằng chúng tôi đã cố gắng tách biệt trách nhiệm thiết kế tập lệnh thử nghiệm và triển khai mã cho nó. Một người tham gia lên kịch bản, phần công việc này do anh chịu trách nhiệm, anh là người nói lời cuối cùng. Và người còn lại chịu trách nhiệm thực hiện. Nó hoạt động tốt. Chất lượng của kịch bản với cách tiếp cận này tăng lên.
Kết luận: than ôi, tốc độ làm việc không cho phép sử dụng bóng bàn như một phương pháp thực hành lập trình cặp trong IaC.
3. Phong cách mạnh mẽ. . Ý tưởng là một người tham gia sẽ trở thành người điều hướng chỉ thị và người thứ hai sẽ đóng vai trò là người điều khiển thực thi. Trong trường hợp này, quyền đưa ra quyết định hoàn toàn thuộc về người điều hướng. Trình điều khiển chỉ in và có thể tác động đến những gì đang xảy ra bằng một từ. Vai trò không thay đổi trong một thời gian dài.
Tốt cho việc học, nhưng đòi hỏi kỹ năng mềm mạnh mẽ. Đây là nơi chúng tôi chùn bước. Kỹ thuật này rất khó khăn. Và nó thậm chí không phải là về cơ sở hạ tầng.
Kết luận: nó có thể được sử dụng, chúng tôi sẽ không từ bỏ việc cố gắng.
4. Di chuyển, bầy đàn và tất cả các phong cách đã biết nhưng chưa được liệt kê Chúng tôi không xem xét nó, bởi vì Chúng tôi chưa thử và không thể nói về nó trong bối cảnh công việc của chúng tôi.
Kết quả chung khi sử dụng lập trình cặp:
- Chúng tôi có tốc độ làm việc không đồng đều, điều này gây nhầm lẫn.
- Chúng tôi không có đủ kỹ năng mềm tốt. Và môn học cũng không giúp khắc phục được những khuyết điểm đó của chúng ta.
- Các bài kiểm tra dài và các vấn đề với các công cụ khiến việc phát triển theo cặp trở nên khó khăn.
5. Mặc dù vậy, vẫn có những thành công. Chúng tôi đã nghĩ ra phương pháp riêng của mình “Hội tụ - Phân kỳ”. Tôi sẽ mô tả ngắn gọn cách nó hoạt động.
Chúng tôi có đối tác lâu dài trong vài ngày (chưa đầy một tuần). Chúng tôi cùng nhau thực hiện một nhiệm vụ. Chúng tôi ngồi cùng nhau một lúc: một người viết, người kia ngồi xem đội hỗ trợ. Sau đó chúng tôi giải tán một thời gian, mỗi người làm một số việc độc lập, rồi chúng tôi lại tụ tập với nhau, đồng bộ rất nhanh, cùng nhau làm việc gì đó rồi lại giải tán.
Lập kế hoạch và truyền thông
Khối thực hành cuối cùng để giải quyết các vấn đề về hệ điều hành là tổ chức công việc với chính các nhiệm vụ đó. Điều này cũng bao gồm việc trao đổi kinh nghiệm ngoài công việc cặp đôi. Chúng ta hãy xem xét ba thực hành:
1. Mục tiêu thông qua cây mục tiêu. Chúng tôi tổ chức quản lý tổng thể dự án thông qua một cái cây hướng tới tương lai vô tận. Về mặt kỹ thuật, việc theo dõi được thực hiện trong Miro. Có một nhiệm vụ - đó là mục tiêu trung gian. Từ đó đi đến các mục tiêu hoặc nhóm nhiệm vụ nhỏ hơn. Bản thân các nhiệm vụ đều đến từ họ. Tất cả các nhiệm vụ được tạo và duy trì trên bảng này.
Kế hoạch này cũng cung cấp phản hồi, xảy ra mỗi ngày một lần khi chúng tôi đồng bộ hóa tại các cuộc biểu tình. Có một kế hoạch chung trước mặt mọi người, nhưng có cấu trúc và hoàn toàn cởi mở, cho phép mọi người nhận thức được những gì đang xảy ra và chúng ta đã tiến bộ đến mức nào.
Ưu điểm của tầm nhìn trực quan của nhiệm vụ:
- Nhân quả. Mỗi nhiệm vụ dẫn đến một số mục tiêu toàn cầu. Nhiệm vụ được nhóm thành các mục tiêu nhỏ hơn. Bản thân lĩnh vực cơ sở hạ tầng mang tính kỹ thuật khá cao. Không phải lúc nào cũng rõ ràng ngay lập tức tác động cụ thể nào, chẳng hạn như việc viết một cuốn sổ tay về việc di chuyển sang nginx khác có tác động gì đến hoạt động kinh doanh. Có thẻ mục tiêu ở gần sẽ rõ ràng hơn.
Tính nhân quả là một thuộc tính quan trọng của vấn đề. Nó trực tiếp trả lời câu hỏi: “Tôi có đang làm đúng không?” - Tính song song. Có chín người trong chúng tôi, và về mặt thể chất, việc giao mọi người vào một nhiệm vụ là điều không thể. Nhiệm vụ từ một khu vực có thể không phải lúc nào cũng đủ. Chúng tôi buộc phải thực hiện song song công việc giữa các nhóm làm việc nhỏ. Đồng thời, các nhóm ngồi thực hiện nhiệm vụ của mình trong một thời gian, họ có thể được người khác hỗ trợ. Đôi khi có người rời khỏi nhóm làm việc này. Ai đó đi nghỉ, ai đó viết báo cáo cho cuộc họp DevOps, ai đó viết một bài báo về Habr. Biết những mục tiêu và nhiệm vụ nào có thể được thực hiện song song trở nên rất quan trọng.
2. Thay thế người thuyết trình trong cuộc họp buổi sáng. Khi đứng lên, chúng tôi gặp phải vấn đề này - mọi người thực hiện nhiều nhiệm vụ song song. Đôi khi các nhiệm vụ được kết nối lỏng lẻo và không hiểu ai đang làm gì. Và ý kiến của một thành viên khác trong nhóm là rất quan trọng. Đây là thông tin bổ sung có thể thay đổi quá trình giải quyết vấn đề. Tất nhiên, thường sẽ có người ở bên bạn, nhưng những lời khuyên và lời khuyên luôn hữu ích.
Để cải thiện tình trạng này, chúng tôi đã sử dụng kỹ thuật “Thay đổi người đứng đầu”. Bây giờ chúng được luân chuyển theo một danh sách nhất định và điều này có tác dụng. Khi đến lượt mình, bạn buộc phải đi sâu vào và hiểu chuyện gì đang xảy ra để điều hành một cuộc họp Scrum thành công.
3. Bản demo nội bộ. Trợ giúp giải quyết vấn đề từ lập trình cặp, trực quan hóa cây vấn đề và trợ giúp tại các cuộc họp scrum vào buổi sáng đều tốt nhưng không lý tưởng. Là một cặp vợ chồng, bạn chỉ bị giới hạn bởi kiến thức của mình. Cây nhiệm vụ giúp hiểu rõ ai đang làm gì trên toàn cầu. Và người thuyết trình và đồng nghiệp trong cuộc họp buổi sáng sẽ không đi sâu vào vấn đề của bạn. Họ chắc chắn có thể bỏ lỡ điều gì đó.
Giải pháp được tìm thấy là chứng minh công việc đã làm cho nhau và sau đó thảo luận về nó. Chúng tôi gặp nhau mỗi tuần một lần trong một giờ và trình bày chi tiết các giải pháp cho các nhiệm vụ chúng tôi đã thực hiện trong tuần qua.
Trong quá trình trình diễn, cần tiết lộ các chi tiết của nhiệm vụ và đảm bảo chứng minh được cách thức hoạt động của nó.
Báo cáo có thể được thực hiện bằng cách sử dụng một danh sách kiểm tra.1. Đi vào bối cảnh. Nhiệm vụ đến từ đâu, tại sao nó lại cần thiết?
2. Vấn đề trước đây được giải quyết như thế nào? Ví dụ: cần phải nhấp chuột nhiều hoặc không thể làm được gì cả.
3. Chúng tôi cải thiện nó như thế nào. Ví dụ: “Nhìn này, bây giờ có scriptosik, đây là readme.”
4. Hãy chỉ ra cách nó hoạt động. Nên trực tiếp thực hiện một số kịch bản người dùng. Tôi muốn X, tôi làm Y, tôi thấy Y (hoặc Z). Ví dụ: tôi triển khai NGINX, hút url và nhận được 200 OK. Nếu hành động kéo dài, hãy chuẩn bị trước để có thể trình chiếu sau. Bạn không nên làm vỡ nó quá nhiều một giờ trước khi trình diễn, nếu nó dễ vỡ.
5. Giải thích vấn đề đã được giải quyết thành công như thế nào, những khó khăn còn tồn tại, những gì chưa hoàn thành, những cải tiến nào có thể thực hiện được trong tương lai. Ví dụ bây giờ là CLI, sau này sẽ có tự động hóa hoàn toàn trong CI.
Mỗi diễn giả nên duy trì thời gian trong 5-10 phút. Nếu bài phát biểu của bạn rõ ràng là quan trọng và sẽ mất nhiều thời gian hơn, hãy điều phối trước việc này trong kênh tiếp quản.
Sau phần gặp mặt trực tiếp luôn có một cuộc thảo luận trong chủ đề. Đây là nơi xuất hiện những phản hồi chúng tôi cần về nhiệm vụ của mình.
Kết quả là, một cuộc khảo sát được thực hiện để xác định tính hữu ích của những gì đang xảy ra. Đây là phản hồi về bản chất của bài phát biểu và tầm quan trọng của nhiệm vụ.
Kết luận dài và những gì tiếp theo
Có vẻ như giọng điệu của bài viết có phần bi quan. Cái này sai. Hai cấp độ phản hồi thấp hơn, cụ thể là kiểm tra và lập trình cặp, sẽ hoạt động. Không hoàn hảo như cách phát triển truyền thống nhưng có tác dụng tích cực từ đó.
Các thử nghiệm, ở dạng hiện tại, chỉ cung cấp phạm vi mã một phần. Nhiều chức năng cấu hình chưa được kiểm tra. Mức độ ảnh hưởng của chúng tới công việc thực tế khi viết code thấp. Tuy nhiên, các thử nghiệm tích hợp có tác dụng và chúng cho phép bạn thực hiện tái cấu trúc một cách an toàn. Đây là một thành tựu lớn. Ngoài ra, với việc chuyển trọng tâm sang phát triển bằng các ngôn ngữ cấp cao (chúng tôi có python, go), vấn đề sẽ không còn nữa. Và bạn không cần phải kiểm tra nhiều về “chất keo”, chỉ cần kiểm tra tích hợp chung là đủ.
Làm việc theo cặp phụ thuộc nhiều hơn vào những người cụ thể. Đó là yếu tố nhiệm vụ và kỹ năng mềm của chúng tôi. Với một số người, nó hoạt động rất tốt, với những người khác, nó lại hoạt động tệ hơn. Chắc chắn có những lợi ích từ việc này. Rõ ràng là ngay cả khi các quy tắc làm việc theo cặp không được tuân thủ đầy đủ, thì việc thực hiện các nhiệm vụ cùng nhau vẫn có tác động tích cực đến chất lượng của kết quả. Cá nhân tôi thấy làm việc theo cặp dễ dàng và thú vị hơn.
Các cách tác động đến hệ điều hành ở cấp độ cao hơn - lập kế hoạch và xử lý các nhiệm vụ một cách chính xác sẽ tạo ra hiệu quả: trao đổi kiến thức chất lượng cao và cải thiện chất lượng phát triển.
Kết luận ngắn gọn trong một dòng
- Những người hành nghề nhân sự làm việc trong IaC nhưng hiệu quả kém hơn.
- Tăng cường những gì hoạt động.
- Hãy đưa ra các cơ chế và cách thực hành đền bù của riêng bạn.
Nguồn: www.habr.com