Câu hỏi “làm thế nào để triển khai devops” đã tồn tại nhiều năm nhưng không có nhiều tài liệu hay. Đôi khi bạn trở thành nạn nhân của những quảng cáo từ những nhà tư vấn kém thông minh, những người cần bán thời gian của họ, bất kể thế nào. Đôi khi đây là những từ mơ hồ, cực kỳ chung chung về cách các con tàu của các tập đoàn lớn cày xới những vùng đất rộng lớn của vũ trụ. Câu hỏi được đặt ra: điều này có quan trọng gì với chúng ta? Tác giả thân mến, bạn có thể trình bày rõ ràng ý tưởng của mình trong một danh sách được không?
Tất cả điều này xuất phát từ thực tế là không có nhiều kinh nghiệm thực tế và hiểu biết về kết quả của những chuyển đổi trong văn hóa công ty đã được tích lũy. Những thay đổi trong văn hóa là vấn đề lâu dài, kết quả của nó sẽ không xuất hiện trong một tuần hay một tháng. Chúng tôi cần một người đủ lớn tuổi để chứng kiến các công ty được xây dựng và thất bại như thế nào trong những năm qua.
John Willis - một trong những cha đẻ của DevOps. John có nhiều thập kỷ kinh nghiệm làm việc với rất nhiều công ty. Gần đây, John bắt đầu nhận thấy những khuôn mẫu cụ thể diễn ra khi làm việc với từng người trong số họ. Bằng cách sử dụng những nguyên mẫu này, John hướng dẫn các công ty trên con đường chuyển đổi DevOps thực sự. Đọc thêm về những nguyên mẫu này trong bản dịch báo cáo của anh ấy từ hội nghị DevOops 2018.
Về diễn giả:
Hơn 35 năm quản lý CNTT, tham gia sáng tạo tiền thân của OpenCloud tại Canonical, tham gia vào 10 công ty khởi nghiệp, hai trong số đó đã được bán cho Dell và Docker. Hiện tại ông là Phó Chủ tịch DevOps và Thực hành Kỹ thuật số tại SJ Technologies.
Tiếp theo là câu chuyện dưới góc nhìn của John.
Tên tôi là John Willis và nơi dễ tìm thấy tôi nhất là trên Twitter, . Tôi có cùng bí danh trên Gmail và GitHub. MỘT bạn có thể tìm thấy các bản ghi video về báo cáo và bài thuyết trình của tôi cho họ.
Tôi có nhiều cuộc gặp với CIO của nhiều công ty lớn. Họ thường phàn nàn rằng họ không hiểu DevOps là gì và tất cả những người cố gắng giải thích điều đó cho họ đều đang nói về một điều gì đó khác. Một phàn nàn phổ biến khác là DevOps không hoạt động, mặc dù có vẻ như các giám đốc đang làm mọi thứ như được giải thích với họ. Chúng ta đang nói về những công ty lớn đã hơn một trăm năm tuổi. Sau khi nói chuyện với họ, tôi đi đến kết luận rằng đối với nhiều vấn đề, không phải công nghệ cao là phù hợp nhất mà là các giải pháp công nghệ tương đối thấp. Trong nhiều tuần, tôi chỉ nói chuyện với mọi người từ các phòng ban khác nhau. Những gì bạn nhìn thấy trong bức ảnh đầu tiên trong bài viết là dự án cuối cùng của tôi, đây là căn phòng trông như thế nào sau ba ngày làm việc.
DevOps là gì?
Quả thực, nếu bạn hỏi 10 người khác nhau, họ sẽ đưa ra 10 câu trả lời khác nhau. Nhưng điều thú vị là: cả 10 câu trả lời trên đều đúng. Không có câu trả lời sai ở đây. Tôi đã tìm hiểu khá sâu về DevOps trong khoảng XNUMX năm và là người Mỹ đầu tiên tham gia DevOpsDay đầu tiên. Tôi sẽ không nói rằng tôi thông minh hơn tất cả những người tham gia DevOps, nhưng hiếm có ai dành nhiều công sức cho nó như vậy. Tôi tin rằng DevOps xảy ra khi nguồn nhân lực và công nghệ kết hợp với nhau. Chúng ta thường quên đi khía cạnh con người, mặc dù chúng ta nói rất nhiều về mọi nền văn hóa.
Bây giờ chúng tôi có rất nhiều dữ liệu, 2000 năm nghiên cứu học thuật, thử nghiệm các lý thuyết ở quy mô công nghiệp. Điều mà những nghiên cứu này cho chúng ta biết là nếu bạn kết hợp một số mô hình hành vi trong văn hóa tổ chức, bạn có thể đạt được tốc độ tăng gấp 5000 lần. Khả năng tăng tốc này được kết hợp bởi sự cải thiện tương đương về độ ổn định. Đây là phép đo định lượng về lợi ích mà DevOps có thể mang lại cho bất kỳ công ty nào. Cách đây vài năm, tôi đã nói chuyện về DevOps với Giám đốc điều hành của một công ty Fortune 5. Khi chuẩn bị cho bài thuyết trình, tôi đã rất lo lắng vì phải tóm tắt kinh nghiệm nhiều năm của mình trong XNUMX phút.
Cuối cùng tôi đã đưa ra những điều sau đây Định nghĩa của DevOps: Đó là một tập hợp các thực tiễn và mô hình cho phép chuyển đổi vốn con người thành vốn tổ chức có hiệu suất cao. Một ví dụ là cách Toyota đã vận hành trong 50 hoặc 60 năm qua.
(Sau đây, các sơ đồ như vậy được cung cấp không phải dưới dạng tài liệu tham khảo mà dưới dạng minh họa. Nội dung của chúng sẽ khác nhau đối với mỗi công ty mới. Tuy nhiên, hình ảnh có thể được xem riêng và phóng to
Một trong những thực hành thành công nhất như vậy là lập bản đồ chuỗi giá trị. Một số cuốn sách hay đã được viết về vấn đề này, trong đó thành công nhất là của Karen Martin. Nhưng trong năm qua, tôi đã đi đến kết luận rằng ngay cả phương pháp này cũng quá công nghệ cao. Nó chắc chắn có nhiều ưu điểm và tôi đã sử dụng nó rất nhiều. Nhưng khi Giám đốc điều hành hỏi bạn tại sao công ty của anh ấy không thể chuyển sang các tuyến đường mới, thì còn quá sớm để nói về việc lập bản đồ dòng giá trị. Có rất nhiều câu hỏi cơ bản hơn cần phải được trả lời trước tiên.
Tôi nghĩ sai lầm mà nhiều đồng nghiệp của tôi mắc phải là họ chỉ đơn giản đưa ra cho công ty một bản hướng dẫn gồm 100 điểm và sau đó sáu tháng quay lại xem điều gì đã xảy ra. Chẳng hạn, ngay cả một sơ đồ tốt như lập bản đồ dòng giá trị cũng có những điểm mù. Sau hàng trăm cuộc phỏng vấn với giám đốc của nhiều công ty khác nhau, tôi đã phát triển một mô hình nhất định cho phép chúng tôi chia vấn đề thành các thành phần của nó và bây giờ chúng ta sẽ thảo luận theo thứ tự từng thành phần này. Trước khi áp dụng bất kỳ giải pháp công nghệ nào, tôi sử dụng mẫu này và kết quả là tất cả các bức tường của tôi đều được bao phủ bởi các sơ đồ. Gần đây tôi đang làm việc với một quỹ tương hỗ và tôi đã thực hiện được 150-XNUMX kế hoạch như vậy.
Văn hóa xấu ăn theo cách tốt cho bữa sáng
Ý tưởng chính là thế này: không có mức độ Lean, Agile, AN TOÀN và DevOps nào sẽ giúp ích nếu bản thân văn hóa của tổ chức không tốt. Nó giống như lặn xuống độ sâu mà không có thiết bị lặn hoặc hoạt động mà không chụp X-quang. Nói cách khác, để diễn giải Drucker và Deming: một nền văn hóa tổ chức tồi sẽ nuốt chửng bất kỳ hệ thống tốt nào mà không gây nghẹt thở cho nó.
Để giải quyết vấn đề chính này, bạn cần thực hiện các bước sau:
- Hiển thị tất cả công việc: bạn cần làm cho tất cả công việc có thể nhìn thấy được. Không phải theo nghĩa là nó nhất thiết phải được hiển thị trên một màn hình nào đó, mà theo nghĩa là nó phải có thể quan sát được.
- Hệ thống quản lý công việc hợp nhất: cần phải thống nhất hệ thống quản lý. Trong vấn đề kiến thức “bộ lạc” và kiến thức thể chế, 9 trên 10 trường hợp nút thắt là con người. Trong cuốn sách vấn đề nằm ở một người duy nhất, Brent, người đã khiến dự án bị chậm tiến độ ba năm. Và tôi gặp những người “Brents” này ở khắp mọi nơi. Để giải quyết những nút thắt này, tôi sử dụng hai mục tiếp theo trong danh sách của chúng tôi.
- Lý thuyết về các ràng buộc Phương pháp luận: lý thuyết về các ràng buộc
- Hack cộng tác: hack cộng tác.
- Toyota Kata (): Tôi sẽ không nói nhiều về Toyota Kata. Nếu quan tâm, trên github của tôi về hầu hết mọi chủ đề này.
- Tổ chức định hướng thị trường: tổ chức định hướng thị trường.
- Kiểm toán viên dịch chuyển sang trái: kiểm toán ở giai đoạn đầu của chu kỳ.
Tôi bắt đầu làm việc với một tổ chức rất đơn giản: Tôi đến công ty và nói chuyện với các nhân viên. Như bạn có thể thấy, không có công nghệ cao. Tất cả những gì bạn cần là một cái gì đó để viết. Tôi tập hợp nhiều nhóm vào một phòng và phân tích những gì họ nói với tôi từ góc nhìn của 7 nguyên mẫu của tôi. Và sau đó tôi tự đưa cho họ một cái bút đánh dấu và yêu cầu họ viết lên bảng tất cả những gì họ đã nói to cho đến nay. Thông thường trong những cuộc họp kiểu này sẽ có một người viết ra mọi thứ và tốt nhất anh ta có thể viết ra 10% cuộc thảo luận. Với phương pháp của tôi, con số này có thể nâng lên khoảng 40%.
(Hình minh họa này có thể được xem riêng )
Cách tiếp cận của tôi dựa trên công trình của William Schneider. ). Cách tiếp cận này dựa trên ý tưởng rằng bất kỳ tổ chức nào cũng có thể được chia thành bốn hình vuông. Đối với tôi, sơ đồ này thường là kết quả của việc làm việc với hàng trăm sơ đồ khác nảy sinh khi phân tích một tổ chức. Giả sử chúng ta có một tổ chức có mức độ kiểm soát cao nhưng năng lực thấp. Đây là một lựa chọn cực kỳ không mong muốn: khi mọi người đều đang tuân thủ quy định nhưng không ai biết phải làm gì.
Một lựa chọn tốt hơn một chút là một lựa chọn có mức độ kiểm soát và năng lực cao. Nếu một công ty như vậy có lãi thì có lẽ nó không cần DevOps. Điều thú vị nhất là được làm việc với một công ty có mức độ kiểm soát cao, năng lực và sự hợp tác thấp nhưng đồng thời có trình độ văn hóa (tu luyện) cao. Điều này có nghĩa là công ty có rất nhiều người thích làm việc ở đó và tỷ lệ luân chuyển lao động thấp.
(Hình minh họa này có thể được xem riêng )
Đối với tôi, có vẻ như những phương pháp với những hướng dẫn cứng nhắc cuối cùng lại cản trở việc đạt được chân lý. Trong ánh xạ dòng giá trị nói riêng, có nhiều quy tắc liên quan đến cách cấu trúc thông tin. Trong giai đoạn đầu của công việc mà tôi đang nói đến bây giờ, không ai cần những quy tắc này. Nếu một người cầm bút mô tả tình hình thực tế của công ty trên bảng thì đây là cách tốt nhất để hiểu tình hình. Thông tin như vậy không đến được với giám đốc. Vào lúc này, thật ngu ngốc khi ngắt lời người đó và nói rằng anh ta đã vẽ sai một loại mũi tên nào đó. Ở giai đoạn này, tốt hơn nên sử dụng các quy tắc đơn giản, ví dụ: có thể tạo sự trừu tượng đa cấp một cách đơn giản bằng cách sử dụng các điểm đánh dấu nhiều màu.
Tôi nhắc lại, không có công nghệ cao. Điểm đánh dấu màu đen mô tả thực tế khách quan về cách mọi thứ hoạt động. Với điểm đánh dấu màu đỏ, mọi người đánh dấu những gì họ không thích về tình hình hiện tại. Điều quan trọng là họ viết điều này, không phải tôi. Khi đến gặp CIO sau cuộc họp, tôi không đưa ra danh sách 10 điều cần khắc phục. Tôi cố gắng tìm kiếm mối liên hệ giữa những gì mọi người trong công ty đang nói và những khuôn mẫu đã được chứng minh hiện có. Cuối cùng, điểm đánh dấu màu xanh lam gợi ý các giải pháp khả thi cho vấn đề.
(Hình minh họa này có thể được xem riêng )
Một ví dụ về cách tiếp cận này hiện được mô tả ở trên. Vào đầu năm nay tôi đã làm việc với một ngân hàng. Những người bảo mật ở đó đã bị thuyết phục rằng họ không nên đến để xem xét thiết kế và yêu cầu.
(Hình minh họa này có thể được xem riêng )
Và sau đó chúng tôi đã nói chuyện với những người từ các bộ phận khác và hóa ra là khoảng 8 năm trước, các nhà phát triển phần mềm đã sa thải nhân viên bảo mật vì họ làm chậm công việc. Và sau đó nó trở thành một lệnh cấm, được coi là đương nhiên. Mặc dù trên thực tế không có lệnh cấm.
Cuộc họp của chúng tôi diễn ra một cách cực kỳ khó hiểu: trong khoảng ba giờ, năm nhóm khác nhau không thể giải thích cho tôi điều gì đang xảy ra giữa mã và quá trình lắp ráp. Và đây có vẻ là điều đơn giản nhất. Hầu hết các chuyên gia tư vấn DevOps đều cho rằng mọi người đều đã biết điều này.
Sau đó, người phụ trách quản trị CNTT, người đã im lặng suốt bốn tiếng đồng hồ, đột nhiên sống dậy khi chúng tôi nói đến chủ đề của anh ấy và khiến chúng tôi bận tâm rất lâu. Cuối cùng, tôi hỏi anh ấy nghĩ gì về cuộc gặp và tôi sẽ không bao giờ quên câu trả lời của anh ấy. Anh ấy nói: “Tôi từng nghĩ rằng ngân hàng của chúng tôi chỉ có hai cách để cung cấp phần mềm, nhưng bây giờ tôi biết rằng có năm cách trong số đó, và tôi thậm chí còn không biết về ba.”
(Hình minh họa này có thể được xem riêng )
Cuộc họp cuối cùng tại ngân hàng này là với nhóm phần mềm đầu tư. Với cô ấy, hóa ra việc viết sơ đồ bằng bút dạ trên một tờ giấy sẽ tốt hơn trên bảng, và thậm chí còn tốt hơn trên bảng thông minh.
Những bức ảnh bạn nhìn thấy chính là phòng họp của khách sạn vào ngày thứ tư trong cuộc gặp của chúng tôi. Và chúng tôi đã sử dụng những sơ đồ này để tìm kiếm các khuôn mẫu, tức là các nguyên mẫu.
Vì vậy, tôi đặt câu hỏi cho công nhân, họ viết ra câu trả lời bằng bút dạ ba màu (đen, đỏ và xanh). Tôi phân tích câu trả lời của họ về nguyên mẫu. Bây giờ hãy thảo luận về tất cả các nguyên mẫu theo thứ tự.
1. Hiển thị tất cả công việc: Hiển thị công việc
Hầu hết các công ty tôi làm việc đều có tỷ lệ công việc chưa biết rất cao. Ví dụ, đây là khi một nhân viên đến gặp một nhân viên khác và chỉ yêu cầu làm điều gì đó. Trong các tổ chức lớn, có thể có 60% công việc không được lập kế hoạch. Và có tới 40% công việc không được ghi lại dưới bất kỳ hình thức nào. Nếu là Boeing, tôi sẽ không bao giờ lên máy bay của họ nữa trong đời. Nếu chỉ ghi lại một nửa công việc thì không biết công việc này có được thực hiện đúng hay không. Tất cả các phương pháp khác đều vô dụng - chẳng ích gì khi cố gắng tự động hóa bất cứ thứ gì, bởi vì 50% đã biết có thể là phần mạch lạc và rõ ràng nhất của công việc, việc tự động hóa phần này sẽ không mang lại kết quả tuyệt vời và điều tồi tệ nhất là mọi thứ đều ở một nửa vô hình. Trong trường hợp không có tài liệu, không thể tìm ra đủ loại hack và công việc ẩn, không tìm ra những nút thắt, chính những “Brents” mà tôi đã nói đến. Có một cuốn sách tuyệt vời của Dominica DeGrandis . Cô ấy tiết lộ năm "rò rỉ thời gian" khác nhau (kẻ trộm thời gian):
- Quá nhiều công việc đang được xử lý (WIP)
- Phụ thuộc không xác định
- Công việc không có kế hoạch
- Các ưu tiên xung đột
- công việc bị bỏ quên
Đây là phân tích rất có giá trị và cuốn sách rất hay, nhưng tất cả lời khuyên này đều vô ích nếu chỉ hiển thị được 50% dữ liệu. Các phương pháp do Dominica đề xuất có thể được sử dụng nếu đạt được độ chính xác trên 90%. Tôi đang nói về những tình huống mà ông chủ giao cho cấp dưới một nhiệm vụ 15 phút, nhưng anh ta phải mất ba ngày; nhưng ông chủ không thực sự biết rằng cấp dưới này đang phụ thuộc vào bốn hoặc năm người khác.
Dự án Phoenix là một câu chuyện tuyệt vời về một dự án đã bị chậm trễ ba năm. Một trong những nhân vật phải đối mặt với việc bị sa thải vì điều này, và anh ta gặp một nhân vật khác được thể hiện như một loại Socrates. Anh ấy giúp tìm ra chính xác những gì đã xảy ra. Hóa ra công ty có một quản trị viên hệ thống, tên là Brent, và mọi công việc bằng cách nào đó đều thông qua anh ta. Tại một cuộc họp, một cấp dưới được hỏi: tại sao mỗi nhiệm vụ kéo dài nửa giờ lại mất cả tuần? Câu trả lời là một cách trình bày rất đơn giản về lý thuyết xếp hàng và định luật Little, và trong bài trình bày này, hóa ra với tỷ lệ lấp đầy 90%, mỗi giờ làm việc mất 9 giờ. Mỗi nhiệm vụ cần được gửi cho bảy người khác, do đó giờ đó trở thành 63 giờ, 7 nhân 9. Điều tôi đang nói là để sử dụng Định luật Little hoặc bất kỳ lý thuyết xếp hàng phức tạp nào, ít nhất bạn cần phải có dữ liệu.
Vì vậy, khi tôi nói về khả năng hiển thị, tôi không có ý nói rằng mọi thứ đều hiển thị trên màn hình mà ít nhất bạn cũng có dữ liệu. Khi họ làm vậy, hóa ra là có một lượng rất lớn công việc không có kế hoạch bằng cách nào đó được gửi đến Brent khi không có nhu cầu. Và Brent là một chàng trai tuyệt vời, anh ấy sẽ không bao giờ nói không, nhưng anh ấy cũng không nói cho ai biết anh ấy làm công việc của mình như thế nào.
Khi công việc được hiển thị, dữ liệu có thể được phân loại gọn gàng (đó là những gì Dominique đang làm trong ảnh), có thể áp dụng tính trừu tượng của rò rỉ năm lần và có thể áp dụng tự động hóa.
2. Hợp nhất hệ thống quản lý công việc: Quản lý tác vụ
Các nguyên mẫu mà tôi đang nói đến là một dạng kim tự tháp. Nếu cái đầu tiên được thực hiện chính xác thì cái thứ hai đã là một loại tiện ích bổ sung. Nhiều trong số này không hiệu quả với các công ty khởi nghiệp, chúng cần được lưu ý đối với các công ty lớn hơn như Fortune 5000. Công ty cuối cùng tôi làm việc có 10 hệ thống bán vé. Một nhóm có Biện pháp khắc phục, một nhóm khác viết một số loại hệ thống của riêng mình, nhóm thứ ba sử dụng Jira và một số thực hiện bằng email. Vấn đề tương tự cũng nảy sinh nếu công ty có 30 đường ống khác nhau, nhưng tôi không có thời gian để thảo luận về tất cả các trường hợp như vậy.
Tôi thảo luận với mọi người chính xác về cách tạo vé, điều gì xảy ra với chúng tiếp theo và cách chúng bị phá vỡ. Điều thú vị nhất là mọi người trong cuộc họp của chúng tôi nói chuyện khá chân thành. Tôi hỏi có bao nhiêu người đặt "tác động nhỏ / không có tác động" lên những tấm vé thực sự có "tác động lớn". Hóa ra hầu hết mọi người đều làm điều này. Tôi không tham gia tố cáo và cố gắng bằng mọi cách có thể để không tiết lộ danh tính của mọi người. Khi họ chân thành thú nhận điều gì đó với tôi, tôi sẽ không tiết lộ người đó. Nhưng khi hầu hết mọi người đều bỏ qua hệ thống, điều đó có nghĩa là tất cả biện pháp bảo mật về cơ bản chỉ là che đậy cửa sổ. Vì vậy, không thể rút ra kết luận nào từ dữ liệu của hệ thống này.
Để giải quyết vấn đề vé, bạn cần chọn một hệ thống chính. Nếu bạn sử dụng Jira, hãy giữ nó Jira. Nếu có bất kỳ sự thay thế nào, hãy để nó là lựa chọn duy nhất. Điểm mấu chốt là vé nên được xem như một bước khác trong quá trình phát triển. Mọi hành động đều phải có phiếu, phiếu này phải chảy qua quy trình phát triển. Vé được gửi đến nhóm, nhóm này sẽ đăng chúng lên bảng phân cảnh và sau đó chịu trách nhiệm về chúng.
Điều này áp dụng cho tất cả các bộ phận, bao gồm cả cơ sở hạ tầng và hoạt động. Trong trường hợp này, có thể hình thành ít nhất một số ý tưởng hợp lý về tình hình. Khi quá trình này được thiết lập, việc xác định ai chịu trách nhiệm cho mỗi ứng dụng sẽ trở nên dễ dàng. Bởi vì bây giờ chúng tôi nhận được không phải 50% mà là 98% dịch vụ mới. Nếu quy trình cốt lõi này hoạt động thì độ chính xác sẽ được cải thiện trên toàn hệ thống.
Đường dẫn dịch vụ
Điều này một lần nữa chỉ áp dụng cho các tập đoàn lớn. Nếu bạn là một công ty mới trong một lĩnh vực mới, hãy xắn tay áo lên và làm việc với Travis CI hoặc CircleCI của bạn. Khi nói đến các công ty Fortune 5000, một trường hợp điển hình đã xảy ra tại ngân hàng nơi tôi làm việc. Google đến gặp họ và họ được cho xem sơ đồ của các hệ thống IBM cũ. Những người ở Google bối rối hỏi - mã nguồn của cái này ở đâu? Nhưng không có mã nguồn, thậm chí không có GUI. Đây là thực tế mà các tổ chức lớn phải đối mặt: hồ sơ ngân hàng 40 năm tuổi trên một máy tính lớn cổ xưa. Một trong những khách hàng của tôi sử dụng các thùng chứa Kubernetes với các mẫu Circuit Breaker, cùng với Chaos Monkey, tất cả đều dành cho ứng dụng KeyBank. Nhưng những vùng chứa này cuối cùng sẽ kết nối với ứng dụng COBOL.
Những người ở Google hoàn toàn tự tin rằng họ sẽ giải quyết được tất cả các vấn đề của khách hàng của tôi và sau đó họ bắt đầu đặt câu hỏi: IBM datapipe là gì? Họ được bảo: đây là một đầu nối. Nó kết nối với cái gì? Đến hệ thống Sperry. Và cái đó là cái gì? Và như thế. Thoạt nhìn có vẻ như: có thể có loại DevOps nào? Nhưng trên thực tế, điều đó là có thể. Có những hệ thống phân phối cho phép bạn bàn giao quy trình làm việc cho nhóm phân phối.
3. Lý thuyết ràng buộc: Lý thuyết ràng buộc
Hãy chuyển sang nguyên mẫu thứ ba: kiến thức về thể chế/bộ lạc. Theo quy định, trong bất kỳ tổ chức nào cũng có một số người biết mọi thứ và quản lý mọi thứ. Đây là những người đã ở trong tổ chức lâu nhất và là người biết mọi cách giải quyết.
Khi điều này xuất hiện trên sơ đồ, tôi đặc biệt khoanh tròn những người như vậy bằng một điểm đánh dấu: ví dụ, hóa ra một Lou nào đó có mặt trong tất cả các cuộc họp. Và tôi thấy rõ: đây là dầu Brent địa phương. Khi CIO chọn giữa tôi mặc áo phông, đi giày thể thao và anh chàng đến từ IBM mặc vest, tôi được chọn vì tôi có thể nói với giám đốc những điều mà người kia sẽ không nói và giám đốc có thể không muốn nghe. . Tôi nói với họ rằng điểm nghẽn trong công ty của họ là một người tên Fred và một người tên Lou. Nút thắt này cần được tháo gỡ, kiến thức của họ cần được tiếp thu từ họ bằng cách này hay cách khác.
Ví dụ: để giải quyết loại vấn đề này, tôi có thể đề xuất sử dụng Slack. Một giám đốc thông minh sẽ hỏi - tại sao? Thông thường, trong những trường hợp như vậy, chuyên gia tư vấn DevOps trả lời: bởi vì mọi người đều đang làm việc đó. Nếu đạo diễn thực sự thông minh, ông ấy sẽ nói: vậy thì sao. Và đây là nơi cuộc đối thoại kết thúc. Và câu trả lời của tôi cho điều này là: bởi vì có bốn điểm nghẽn trong công ty là Fred, Lou, Susie và Jane. Để thể chế hóa kiến thức của họ, trước tiên người ta phải giới thiệu Slack. Tất cả các wiki của bạn hoàn toàn vô nghĩa vì không ai biết về sự tồn tại của chúng. Nếu nhóm kỹ thuật tham gia phát triển front-end và back-end và mọi người cần biết rằng họ có thể liên hệ với nhóm phát triển front-end hoặc nhóm cơ sở hạ tầng nếu có thắc mắc. Đó là lúc Lou hoặc Fred có thể sẽ có thời gian tham gia wiki. Và sau đó trong Slack, ai đó có thể hỏi tại sao, chẳng hạn như bước 5 không hoạt động. Sau đó Lou hoặc Fred sẽ sửa hướng dẫn trên wiki. Nếu bạn thiết lập quy trình này, thì rất nhiều thứ sẽ tự diễn ra.
Đây là điểm chính của tôi: để đề xuất bất kỳ công nghệ cao nào, trước tiên bạn phải đặt nền tảng cho chúng theo thứ tự và điều này có thể được thực hiện bằng các giải pháp công nghệ thấp vừa mô tả. Nếu bạn bắt đầu với công nghệ cao và không giải thích lý do tại sao chúng cần thiết, thì theo quy luật, điều này sẽ không có kết thúc tốt đẹp. Một trong những khách hàng của chúng tôi sử dụng Azure ML, một giải pháp rất rẻ và đơn giản. Khoảng 30% câu hỏi của họ đã được chính máy tự học trả lời. Và thứ này được viết bởi những người vận hành không liên quan đến khoa học dữ liệu, thống kê hoặc toán học. Điều này rất quan trọng. Chi phí của một giải pháp như vậy là tối thiểu.
4. Hack cộng tác: Hack cộng tác
Nguyên mẫu thứ tư là nhu cầu chống lại sự cô lập. Hầu hết mọi người đều biết điều này: sự cô lập sinh ra sự thù địch. Nếu mỗi bộ phận nằm trên một tầng riêng và mọi người không giao nhau bằng bất kỳ cách nào, ngoại trừ trong thang máy, thì sự thù địch giữa họ rất dễ nảy sinh. Nhưng ngược lại, nếu có người ở cùng phòng với nhau thì cô ấy lập tức bỏ đi. Ví dụ, khi ai đó đưa ra một số lời buộc tội chung chung, giao diện như vậy và như vậy không bao giờ hoạt động, thì không có gì dễ dàng hơn để giải mã một lời buộc tội như vậy. Các lập trình viên viết giao diện chỉ cần bắt đầu đặt các câu hỏi cụ thể và sẽ sớm thấy rõ rằng, chẳng hạn, người dùng chỉ đơn giản là sử dụng công cụ không chính xác.
Có nhiều cách để vượt qua sự cô lập. Có lần tôi được mời tư vấn cho một ngân hàng ở Úc nhưng tôi từ chối vì tôi có hai con và một vợ. Tất cả những gì tôi có thể làm để giúp họ là giới thiệu cách kể chuyện bằng đồ họa. Đây là một cái gì đó đã được chứng minh là có hiệu quả. Một cách thú vị khác là các cuộc họp cà phê nạc. Trong một tổ chức lớn, đây là một lựa chọn tuyệt vời để phổ biến kiến thức. Ngoài ra, bạn có thể tiến hành các ngày hội nghị nội bộ, hackathons, v.v.
5. Huấn luyện Kata
Như tôi đã cảnh báo ngay từ đầu, hôm nay tôi sẽ không nói về vấn đề này. Nếu bạn quan tâm có thể xem qua .
Ngoài ra còn có một bài nói hay về chủ đề này từ Mike Rother:
6. Định hướng thị trường: tổ chức định hướng thị trường
Có nhiều vấn đề khác nhau ở đây. Ví dụ: người "I", người "T" và người "E". Người “tôi” là những người chỉ làm một việc. Thông thường họ tồn tại trong các tổ chức có các phòng ban biệt lập. "T" là khi một người giỏi một thứ nhưng cũng giỏi một số thứ khác. “E” hay thậm chí “lược” là khi một người có nhiều kỹ năng.
Định luật Conway có tác dụng ở đây (), ở dạng đơn giản nhất có thể được phát biểu như sau: nếu ba nhóm làm việc trên trình biên dịch, thì kết quả sẽ là một trình biên dịch gồm ba phần. Do đó, nếu có mức độ cô lập cao trong một tổ chức, thì ngay cả Kubernetes, Circuit breaker, khả năng mở rộng API và những thứ ưa thích khác trong tổ chức này cũng sẽ được sắp xếp giống như chính tổ chức đó. Đúng theo Conway và chọc tức tất cả những kẻ lập dị trẻ tuổi như các bạn.
Giải pháp cho vấn đề này đã được mô tả nhiều lần. Ví dụ, có những nguyên mẫu tổ chức được Fernando Fernandez mô tả. Kiến trúc có vấn đề mà tôi vừa nói đến, với sự cô lập, là kiến trúc hướng chức năng. Loại thứ hai là loại tệ nhất, kiến trúc ma trận, một mớ hỗn độn của hai loại còn lại. Thứ ba là điều thường thấy ở hầu hết các công ty khởi nghiệp, và các công ty lớn cũng đang cố gắng bắt kịp loại hình này. Đây là một tổ chức định hướng thị trường. Tại đây chúng tôi tối ưu hóa để đạt được phản hồi nhanh nhất cho yêu cầu của khách hàng. Điều này đôi khi được gọi là một tổ chức phẳng.
Nhiều người mô tả cấu trúc này theo nhiều cách khác nhau, tôi thích cách diễn đạt xây dựng/điều hành đội, ở Amazon họ gọi nó là hai đội pizza. Trong cấu trúc này, tất cả những người thuộc loại “I” được nhóm lại xung quanh một dịch vụ và dần dần họ trở nên gần gũi hơn với loại “T” và nếu có sự quản lý phù hợp, họ thậm chí có thể trở thành “E”. Phản biện đầu tiên ở đây là cấu trúc như vậy có những yếu tố không cần thiết. Tại sao bạn cần một người thử nghiệm ở mỗi bộ phận nếu bạn có thể có một bộ phận người thử nghiệm đặc biệt? Tôi trả lời: chi phí tăng thêm trong trường hợp này là cái giá để toàn bộ tổ chức trở thành loại “E” trong tương lai. Trong cấu trúc này, người kiểm thử dần dần tìm hiểu về mạng, kiến trúc, thiết kế, v.v. Kết quả là mọi người tham gia vào tổ chức đều nhận thức đầy đủ về mọi việc xảy ra trong tổ chức. Nếu bạn muốn biết chương trình này hoạt động như thế nào trong ngành, hãy đọc .
7. Kiểm toán viên Shift-left: kiểm tra sớm trong chu kỳ. Tuân thủ các quy định an toàn khi trưng bày
Có thể nói đây là lúc hành động của bạn không vượt qua được bài kiểm tra mùi. Những người làm việc cho bạn không hề ngu ngốc. Nếu, như trong ví dụ trên, họ đặt ra tác động nhỏ/không có tác động ở mọi nơi, việc này kéo dài ba năm và không ai nhận thấy điều gì, thì mọi người đều biết rõ rằng hệ thống không hoạt động. Hoặc một ví dụ khác - một ban cố vấn thay đổi, nơi các báo cáo cần được gửi vào thứ Tư hàng tuần. Có một nhóm người làm việc ở đó (nhân tiện, lương không cao lắm), về mặt lý thuyết, họ nên biết toàn bộ hệ thống hoạt động như thế nào. Và trong XNUMX năm qua, có lẽ bạn đã nhận thấy rằng hệ thống của chúng tôi cực kỳ phức tạp. Và năm hoặc sáu người phải đưa ra quyết định về một thay đổi mà họ không thực hiện và họ không biết gì về nó.
Tất nhiên, cách tiếp cận này không hiệu quả. Tôi phải loại bỏ những thứ như vậy vì những người này không bảo vệ hệ thống. Quyết định phải do chính đội đưa ra, vì đội phải chịu trách nhiệm về việc đó. Mặt khác, một tình huống nghịch lý sẽ nảy sinh khi một người quản lý chưa bao giờ viết mã trong đời nói với người lập trình viên rằng phải mất bao lâu để viết mã. Một công ty mà tôi làm việc cùng có 7 hội đồng khác nhau xem xét mọi thay đổi, bao gồm hội đồng kiến trúc, hội đồng sản phẩm, v.v. Thậm chí còn có một khoảng thời gian chờ đợi bắt buộc, mặc dù một nhân viên nói với tôi rằng trong mười năm làm việc, chưa có ai từ chối một thay đổi nào do người này thực hiện trong khoảng thời gian bắt buộc này.
Kiểm toán viên cần được mời tham gia cùng chúng tôi chứ không phải loại bỏ họ. Nói với họ rằng bạn viết các vùng chứa nhị phân bất biến, nếu chúng vượt qua tất cả các bài kiểm tra, sẽ không thay đổi mãi mãi. Nói với họ rằng bạn có một quy trình dưới dạng mã và giải thích điều đó có nghĩa là gì. Cho họ xem sơ đồ sau: một tệp nhị phân chỉ đọc bất biến trong một vùng chứa đã vượt qua tất cả các bài kiểm tra lỗ hổng bảo mật; và sau đó không những không ai chạm vào nó, thậm chí họ còn không chạm vào hệ thống tạo ra đường ống, vì nó cũng được tạo ra một cách linh hoạt. Tôi có khách hàng, Capital One, đang sử dụng Vault để tạo ra thứ gì đó giống như chuỗi khối. Kiểm toán viên không cần đưa ra “công thức nấu ăn” từ Chef, chỉ cần hiển thị blockchain là đủ, từ đó biết rõ chuyện gì đã xảy ra với tấm vé Jira trong quá trình sản xuất và ai chịu trách nhiệm về việc đó.
Theo , được Sonatype tạo ra vào năm 2018, đã có 2017 tỷ yêu cầu tải xuống OSS trong năm 87.
Những tổn thất phát sinh do lỗ hổng bảo mật là rất lớn. Hơn nữa, những con số bạn thấy ở trên không bao gồm chi phí cơ hội. Tóm lại DevSecOps là gì? Hãy để tôi nói ngay rằng tôi không muốn nói về mức độ thành công của cái tên này. Vấn đề là vì DevOps đã rất thành công nên chúng ta nên cố gắng tăng cường bảo mật cho quy trình đó.
Một ví dụ về trình tự này:
Đây không phải là đề xuất cho các sản phẩm cụ thể, mặc dù tôi thích tất cả chúng. Tôi lấy chúng làm ví dụ cho thấy rằng DevOps, ban đầu dựa trên mô hình tổ chức trong ngành, cho phép bạn tự động hóa mọi giai đoạn làm việc trên một sản phẩm.
Và không có lý do gì chúng ta không thể áp dụng cách tiếp cận tương tự đối với vấn đề bảo mật.
Tổng
Để kết luận, tôi sẽ đưa ra một số lời khuyên cho DevSecOps. Bạn cần mời các kiểm tra viên tham gia vào quá trình tạo hệ thống của mình và dành thời gian đào tạo họ. Bạn cần hợp tác với kiểm toán viên. Tiếp theo, bạn cần tiến hành một cuộc chiến hoàn toàn tàn nhẫn chống lại những kết quả dương tính giả. Ngay cả với công cụ quét lỗ hổng đắt tiền nhất, bạn vẫn có thể tạo ra những thói quen cực kỳ xấu cho các nhà phát triển của mình nếu bạn không biết tỷ lệ tín hiệu trên nhiễu của mình là bao nhiêu. Các nhà phát triển sẽ bị choáng ngợp bởi các sự kiện và sẽ đơn giản xóa chúng đi. Nếu bạn đã nghe về câu chuyện Equachus, thì đó gần như là những gì đã xảy ra ở đó, nơi mức cảnh báo cao nhất đã bị bỏ qua. Ngoài ra, các lỗ hổng cần được giải thích theo cách làm rõ chúng tác động như thế nào đến doanh nghiệp. Ví dụ: bạn có thể nói rằng đây là lỗ hổng tương tự như trong câu chuyện Equifax. Các lỗ hổng bảo mật phải được xử lý giống như các sự cố phần mềm khác, nghĩa là chúng phải được đưa vào quy trình DevOps tổng thể. Bạn cần làm việc với họ thông qua Jira, Kanban, v.v. Các nhà phát triển không nên nghĩ rằng người khác sẽ làm việc này - ngược lại, mọi người đều nên làm việc này. Cuối cùng, bạn cần dành sức lực cho việc đào tạo con người.
Liên kết hữu ích
Dưới đây là một số bài nói chuyện từ hội nghị DevOops mà bạn có thể thấy hữu ích:
- Sergey Berdnikov, Artyom Kalichkin - Câu chuyện thành công, hay “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps trên quy mô: một bi kịch Hy Lạp gồm ba màn (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister -
Nhìn vào DevOops 2020 Mátxcơva - ở đó cũng có rất nhiều điều thú vị.
Nguồn: www.habr.com