Tăng tính linh hoạt của DevOps - tuân thủ 3 quy tắc này để cải thiện giao tiếp giữa DevOps và Developers

toannm

Giới thiệu: Tăng sự linh hoạt của DevOps thông qua giao tiếp tuyệt vời

Các công ty công nghệ đang nỗ lực để kết hợp các nguyên tắc DevOps linh hoạt để phát hành và tiếp cận thị trường nhanh hơn.

Bài đăng đầu tiên sẽ tập trung vào giao tiếp tốt, điều này hoàn toàn quan trọng đối với một công ty linh hoạt. Phát hành nhanh hơn có nghĩa là developers và các nhân viên DevOps luôn phải cùng thống nhất. Giao tiếp không phải là một công cụ hào nhoáng nhưng bắt buộc phải có ở trong một tổ chức linh hoạt. Có thể thấy sự hỗn loạn, lãng phí thời gian và sự nhầm lẫn xảy ra khi giao tiếp không tốt- hoàn thành các nhiệm vụ tốn gấp đôi thời gian cần thiết. Các nhóm đều muốn phát triển và hoàn thành công việc nhanh hơn, nhưng điều này phản tác dụng khi mỗi thành viên trong nhóm cái nhìn khác nhau về những công việc cần làm, các giả định không phù hợp hoặc mọi thứ hoạt động không theo thứ tự. Làm thế nào để đảm bảo những điều trên không xảy ra? Developers và nhóm DevOps phải giao tiếp tốt để hiểu mong đợi và nhu cầu khi cung cấp ứng dụng của cả hai bên. Không có sự hiểu biết này thì không thể cung cấp một ứng dụng.

Nhiều người khi đọc bài đăng trên blog này, có lẽ sẽ nghĩ, 'Tôi đã biết điều này! Tôi không học được gì mới.' Dù vậy, biết cách làm một việc và kiên định làm như vậy là hai điều khác nhau. Các vấn đề do giao tiếp chưa tốt phát sinh khi mọi người cảm thấy thời gian gấp gáp hoặc dự án này ‘không cần’ nỗ lực giao tiếp tốt. Hãy nghĩ về bài đăng blog này như một lời nhắc nhở thân thiện về việc thể hiện các nguyên tắc giao tiếp này 100% thời gian, làm gương tốt cho các thành viên còn lại trong nhomas và nhẹ nhàng sửa lỗi cho đồng đội khi họ làm trái các nguyên tắc.

Chiến lược 1: Thiết lập các định mức giao tiếp nhóm bằng cách sử dụng tốt các công cụ giao tiếp hiện có.

Các công cụ giao tiếp đang được sử dụng tại nơi làm việc chỉ hiệu quả như các chuẩn mực giao tiếp nơi làm việc. Nếu ai đó nói về một vấn đề offline với một người khác tại scrum hoặc có câu hỏi mơ hồ phức tạp trong Slack, mọi người trong nhóm đều sẽ gặp khó khăn. Dưới đây là các tiêu chuẩn được đề xuất (có thể khác với mỗi công ty, tùy thuộc vào quy mô và cách tổ chức các nhóm):

Sử dụng Slack

Nên:
  • Hãy cụ thể. Cố gắng tránh những từ mơ hồ như: nó, anh ấy/cô ấy, họ, đó.
  • Phân luồng để hợp lý hóa các cuộc hội thoại kênh
  • Sử dụng Tin nhắn trực tiếp thay vì kênh - hãy tự hỏi “có phải tất cả mọi người đều cần nghe điều này không?”
  • Scrums
Nên:
  • Cần sử dụng công cụ này hàng ngày trong 15 phút
  • Sử dụng để cập nhật nhanh câu hỏi
  • Xác định những người cần làm việc cùng nhau để giải quyết vấn đề và thiết lập thời gian bên ngoài scrum, để thảo luận

Không nên:
  • Sử dụng diễn đàn này như thời gian để hai hoặc ba người cùng nhau giải quyết vấn đề trong khi cả nhóm theo dõi
  • Email
Nên:
  • Nếu công ty thường giao tiếp qua email, hãy sử dụng email
  • Sử dụng cho giao tiếp bên ngoài
Không nên:
  • Nếu các cuộc hội thoại nội bộ tại công ty chủ yếu diễn ra ở Slack, đừng viết email với một nhóm người. Họ có thể không phản hồi vì không kiểm tra email thường xuyên và điều đó chia nhỏ cuộc trò chuyện thành hai phương tiện
Chiến lược 2: Tài liệu, tài liệu, và tài liệu

Tài liệu đòi hỏi một khoản đầu tư trả trước, nhưng sẽ có ích về lâu dài. Đôi khi sẽ có suy nghĩ như “dự án này rất đơn giản và không cần tài liệu”. Đừng rơi vào cái bẫy đó - các dự án thường trở nên phức tạp hơn và thậm chí dự án đơn giản của mỗi người đều không giống nhau. Lúc đưa ra ý tưởng thì luôn đơn giản. Hãy nghĩ về 6 tháng sau, liệu các chi tiết còn được ghi nhớ không? Nếu có người rời đi sẽ cần bàn giao công việc gì? Liệu họ có hiểu những quyết định đã được đưa ra cho đến thời điểm này?

DevOps phải soạn tài liệu từng bước rất chi tiết về cách tạo cơ sở hạ tầng. Ban đầu, điều này giúp developer ứng dụng hiểu những gì diễn ra trong quá trình triển khai sản xuất và các vấn đề có thể phát sinh. Điều này cũng sẽ giúp nhóm DevOps trong tương lai, sau khi ứng dụng được triển khai, khi cần cập nhật ứng dụng (điều mà sẽ xảy ra, ngay cả khi nó chỉ là một lần duy nhất). Việc triển khai sau đó có thể không được dẫn dắt bởi cùng một người đã triển khai ứng dụng ban đầu và tài liệu này giúp xây dựng kiến thức tổ chức. Tài liệu này cũng có thể hướng dẫn công việc có thể tự động hóa. Việc tự động hóa trong tương lai sẽ dễ dàng hơn nếu có hướng dẫn chi tiết.

Hãy nhớ rằng tài liệu không nhất thiết chỉ toàn chữ - có thể sử dụng sơ đồ trong tài liệu. Hình ảnh đáng giá cả ngàn lời nói và điều này cũng đúng trong giao tiếp của DevOps/developer. Chọn sơ đồ chính xác để mô tả các yêu cầu là điều cần thiết. Hãy lên ý tưởng và dừng lại một chút để suy nghĩ xem liệu sơ đồ sẽ thể hiện suy nghĩ tốt hơn lời nói không. Làm thế nào hình dung được vấn đề cần giải thích? Nên sử dụng sơ đồ quy trình? Sơ đồ thang hay Sơ đồ mạng? Hình ảnh sẽ biểu cảm và sinh động hơn.

Nếu đang xây dựng một đường ống, thật tốt nếu có tài liệu nhưng thông thường tạo một sơ đồ luồng để biểu thị thông tin cần thiết sẽ tốt hơn. Nó cho phép bạn xem các điểm bắt đầu, các nhánh khác nhau trong khi xem tài liệu sẽ khó theo dõi hơn. Sơ đồ quy trình rất phù hợp để mô tả một đường ống CI/CD bởi vì rất dễ hiểu và có thể biến sơ đồ thành mã. Developer không cần diễn giải nghĩa của từ. Chỉ cần nhìn vào sơ đồ và hiểu rõ các đầu vào, hành động và đầu ra ở mỗi bước.

Flow-diagram-large.png


Cuối cùng, viết tài liệu sẽ không có ý nghĩa nếu nó biến mất. Cần có một vị trí trung tâm để lưu trữ tất cả các tài liệu và đảm bảo rằng nó được tổ chức tốt để có thể tìm kiếm!

Chiến lược 3: Thể hiện mọi thứ trong Git (và tự động hóa mọi lúc có thể!)

Thể hiện mọi thứ trong Git (mã và cấu hình) là một cách hiệu quả để mô tả công việc cần làm - hãy nghĩ về nó như một tài liệu trong mã bất biến. Ví dụ, developer ứng dụng biết cách xây dựng ứng dụng và chạy ứng dụng cục bộ nhưng không có nhiều thông tin về cách ứng dụng sẽ được triển khai ra môi trường sản xuất. Ngược lại, nhóm DevOps biết ứng dụng sẽ hoặc nên được triển khai ra môi trường sản xuất như thế nào nhưng không biết cách xây dựng ứng dụng. Thách thức dành cho developer và các thành viên nhóm DevOps là nhanh chóng trao đổi thông tin và vẫn giữ được tính toàn vẹn của thông tin.

Lý tưởng nhất là mỗi hoạt động nên được tự động hóa 100% để có thể lặp lại và sẽ luôn hoạt động theo cùng một cách. Có thể xây dựng ứng dụng từ nguồn với một tập lệnh ghi lại cách thực hiện hoạt động đó. Về mặt cơ sở hạ tầng, mọi thứ cũng nên được tự động hóa về cách triển khai mọi thứ, bao gồm tạo cơ sở dữ liệu, hàng đợi, S3 buckets và bất cứ thứ gì khác mà ứng dụng cần.

Kết luận: Giao tiếp tuyệt vời đem đến một nhóm linh hoạt hơn

Tăng tính linh hoạt của DevOps có nghĩa là thực hiện các thay đổi cơ bản cho công ty. Điều này có nghĩa là thay đổi định mức, tạo ra các hành vi lặp lại và đảm bảo rằng mọi thành viên trong nhóm đều có cái nhìn này. Giao tiếp tốt có nghĩa là tất cả mọi người có thể cùng nhau diễu hành trên một con đường, và tránh những hiểu lầm bực bội và mất thời gian. Giao tiếp diễn ra theo nhiều cách khác nhau và cần đảm bảo tuân thủ các nguyên tắc giao tiếp tốt trong tất cả các trường hợp sau:

Địa điểm: trực tuyến, trực tiếp, qua điện thoại hoặc trò chuyện video

Thời gian: trong thời gian thực, không đồng bộ, được lưu giữ trong tài liệu

Phương pháp: lời nói, văn bản, thông qua mã và cấu hình

Vì vậy, hãy nhớ - thiết lập các chuẩn mực giao tiếp tốt, tài liệu và thể hiện mọi thứ trong Git!

Tăng tính linh hoạt của DevOps với ManagedKube’s k8sBot

k8sBot được tạo ra để tạo điều kiện giao tiếp tốt hơn về Kubernetes. Đây là một ứng dụng Slack cung cấp thông tin của Kubernetes cluster với giao diện người dùng dễ trỏ-và-nhấp. Chỉ với một cú nhấp chuột, có thể truy xuất trạng thái nhóm, nhận nhật ký nhóm và nhận các đề xuất khắc phục sự cố.

Bất cứ ai, bất kể có truy cập kubectl hoặc kiến thức k8s, đều có thể nhận được thông tin Kubernetes có ý nghĩa với giao diện trỏ-và-nhấp:

k8sbot-database-example.png
 
Top