Anton Weiss, người sáng lập và giám đốc của Otomato Software, một trong những người khởi xướng và hướng dẫn chứng nhận DevOps đầu tiên ở Israel, đã phát biểu tại hội nghị năm ngoái về lý thuyết hỗn loạn và các nguyên tắc chính của kỹ thuật hỗn loạn, đồng thời giải thích cách thức hoạt động của tổ chức DevOps lý tưởng trong tương lai.
Chúng tôi đã chuẩn bị một phiên bản văn bản của báo cáo.
Chào buổi sáng!
DevOpsDays ở Moscow năm thứ hai liên tiếp, đây là lần thứ hai tôi đứng trên sân khấu này, nhiều bạn đã có mặt tại căn phòng này lần thứ hai. Nó có nghĩa là gì? Điều này có nghĩa là phong trào DevOps ở Nga đang phát triển, nhân rộng và quan trọng nhất là đã đến lúc nói về DevOps là gì trong năm 2018.
Ai cho rằng DevOps đã là một nghề trong năm 2018 thì giơ tay? Có như vậy. Có kỹ sư DevOps nào trong phòng có mô tả công việc là “Kỹ sư DevOps” không? Có người quản lý DevOps nào trong phòng không? Không có như vậy. Kiến trúc sư DevOps? Cũng không. Không đủ. Có thật là không ai nói họ là kỹ sư DevOps không?
Vậy đa số các bạn cho rằng đây là anti-pattern? Rằng một nghề như vậy không nên tồn tại? Chúng ta có thể nghĩ bất cứ điều gì chúng ta muốn, nhưng trong khi chúng ta đang suy nghĩ, ngành công nghiệp đang nghiêm túc hướng tới tiếng kèn DevOps.
Ai đã nghe về một chủ đề mới có tên DevDevOps? Đây là một kỹ thuật mới cho phép cộng tác hiệu quả giữa nhà phát triển và nhà phát triển. Và không quá mới. Đánh giá trên Twitter, họ đã bắt đầu nói về điều này từ 4 năm trước. Và cho đến nay, sự quan tâm đến vấn đề này ngày càng tăng, tức là có một vấn đề. Vấn đề cần được giải quyết.
Chúng tôi là những người sáng tạo, chúng tôi không chỉ nghỉ ngơi thoải mái. Chúng tôi nói: DevOps không phải là một từ đủ toàn diện; nó vẫn thiếu đủ loại yếu tố thú vị, khác biệt. Và chúng tôi đi đến phòng thí nghiệm bí mật của mình và bắt đầu tạo ra những đột biến thú vị: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logic thật sắt đá, phải không? Hệ thống phân phối của chúng tôi không hoạt động, hệ thống của chúng tôi không ổn định và người dùng không hài lòng, chúng tôi không có thời gian để tung ra phần mềm đúng hạn, chúng tôi không phù hợp với ngân sách. Chúng ta sẽ giải quyết tất cả chuyện này như thế nào? Chúng ta sẽ nghĩ ra một từ mới! Nó sẽ kết thúc bằng "Ops" và vấn đề đã được giải quyết.
Vì vậy, tôi gọi phương pháp này là - "Rất tiếc, và vấn đề đã được giải quyết."
Tất cả điều này sẽ mờ dần nếu chúng ta nhắc nhở bản thân tại sao chúng ta lại nghĩ ra tất cả những điều này. Chúng tôi đã nghĩ ra toàn bộ giải pháp DevOps này để giúp việc phân phối phần mềm và công việc của chúng tôi trong quá trình này diễn ra suôn sẻ, không gây đau đớn, hiệu quả và quan trọng nhất là thú vị nhất có thể.
DevOps phát triển từ nỗi đau. Và chúng ta mệt mỏi vì đau khổ. Và để tất cả những điều này xảy ra, chúng tôi dựa vào các phương pháp thực hành thường xanh: cộng tác hiệu quả, thực hành quy trình và quan trọng nhất là tư duy hệ thống, vì nếu không có nó thì DevOps sẽ không hoạt động.
Hệ thống là gì?
Và nếu chúng ta đang nói về tư duy hệ thống, hãy tự nhắc nhở bản thân hệ thống là gì.
Nếu bạn là một hacker mang tính cách mạng thì đối với bạn, hệ thống này rõ ràng là xấu xa. Đó là một đám mây che phủ bạn và buộc bạn phải làm những việc bạn không muốn làm.
Theo quan điểm của tư duy hệ thống, hệ thống là một tổng thể bao gồm các bộ phận. Theo nghĩa này, mỗi chúng ta là một hệ thống. Các tổ chức chúng ta làm việc đều là những hệ thống. Và cái mà bạn và tôi đang xây dựng được gọi là một hệ thống.
Tất cả điều này là một phần của một hệ thống công nghệ xã hội lớn. Và chỉ khi chúng ta hiểu cách hệ thống công nghệ xã hội này hoạt động cùng nhau, thì chỉ khi đó chúng ta mới có thể thực sự tối ưu hóa điều gì đó trong vấn đề này.
Từ góc độ tư duy hệ thống, một hệ thống có nhiều đặc tính thú vị khác nhau. Đầu tiên, nó bao gồm các bộ phận, có nghĩa là hoạt động của nó phụ thuộc vào hoạt động của các bộ phận. Hơn nữa, tất cả các bộ phận của nó cũng phụ thuộc lẫn nhau. Hóa ra là một hệ thống càng có nhiều bộ phận thì càng khó hiểu hoặc khó dự đoán hành vi của nó.
Từ quan điểm hành vi, có một sự thật thú vị khác. Hệ thống có thể làm được điều gì đó mà không bộ phận riêng lẻ nào của nó có thể làm được.
Như Tiến sĩ Russell Ackoff (một trong những người sáng lập ra tư duy hệ thống) đã nói, điều này khá dễ chứng minh bằng một thí nghiệm tư duy. Ví dụ, ai trong phòng biết viết mã? Có rất nhiều bàn tay, và điều này là bình thường, bởi vì đây là một trong những yêu cầu chính đối với nghề nghiệp của chúng tôi. Bạn biết viết nhưng tay bạn có thể viết code riêng biệt được không? Có những người sẽ nói: “Không phải tay tôi viết mã mà chính bộ não của tôi viết mã”. Bộ não của bạn có thể viết mã riêng biệt với bạn không? Vâng, có lẽ là không.
Bộ não là một cỗ máy tuyệt vời, chúng ta thậm chí không biết 10% cách nó hoạt động ở đó, nhưng nó không thể hoạt động tách biệt khỏi hệ thống là cơ thể chúng ta. Và điều này rất dễ chứng minh: hãy mở hộp sọ của bạn, lấy bộ não của bạn ra, đặt nó trước máy tính, để anh ấy thử viết một cái gì đó đơn giản. Ví dụ: "Xin chào thế giới" bằng Python.
Nếu một hệ thống có thể làm điều gì đó mà không bộ phận nào của nó có thể làm riêng lẻ thì điều này có nghĩa là hành vi của nó không được xác định bởi hành vi của các bộ phận. Vậy thì nó được xác định bởi cái gì? Nó được xác định bởi sự tương tác giữa các bộ phận này. Và theo đó, càng nhiều bộ phận, tương tác càng phức tạp thì càng khó hiểu và khó dự đoán hành vi của hệ thống. Và điều này làm cho một hệ thống như vậy trở nên hỗn loạn, bởi vì bất kỳ thay đổi nào, thậm chí là nhỏ nhất, vô hình trong bất kỳ phần nào của hệ thống đều có thể dẫn đến những kết quả hoàn toàn không thể đoán trước.
Độ nhạy này với các điều kiện ban đầu lần đầu tiên được phát hiện và nghiên cứu bởi nhà khí tượng học người Mỹ Ed Lorenz. Sau đó, nó được gọi là “hiệu ứng cánh bướm” và dẫn đến sự phát triển của một phong trào tư tưởng khoa học gọi là “lý thuyết hỗn loạn”. Lý thuyết này đã trở thành một trong những thay đổi mô hình lớn trong khoa học thế kỷ 20.
lý thuyết hỗn loạn
Những người nghiên cứu sự hỗn loạn tự gọi mình là nhà hỗn loạn.
Trên thực tế, lý do của báo cáo này là vì khi làm việc với các hệ thống phân tán phức tạp và các tổ chức quốc tế lớn, đến một lúc nào đó tôi nhận ra rằng đây chính là người mà tôi cảm thấy thích. Tôi là một nhà hỗn loạn học. Về cơ bản, đây là một cách nói thông minh: “Tôi không hiểu chuyện gì đang xảy ra ở đây và tôi không biết phải làm gì với nó”.
Tôi nghĩ rằng nhiều bạn cũng thường xuyên cảm thấy như vậy nên các bạn cũng là những nhà hỗn loạn học. Tôi mời bạn đến hội các nhà hỗn loạn học. Các hệ thống mà bạn và tôi, những nhà nghiên cứu hỗn loạn thân mến, sẽ nghiên cứu được gọi là “các hệ thống thích ứng phức tạp”.
Khả năng thích ứng là gì? Khả năng thích ứng có nghĩa là hành vi cá nhân và tập thể của các bộ phận trong một hệ thống thích ứng như vậy thay đổi và tự tổ chức, phản ứng với các sự kiện hoặc chuỗi sự kiện vi mô trong hệ thống. Nghĩa là, hệ thống thích ứng với những thay đổi thông qua việc tự tổ chức. Và khả năng tự tổ chức này dựa trên sự hợp tác tự nguyện, hoàn toàn phi tập trung của các tác nhân tự trị tự do.
Một đặc tính thú vị khác của các hệ thống như vậy là chúng có khả năng mở rộng tự do. Điều chắc chắn sẽ khiến chúng ta quan tâm, với tư cách là các nhà nghiên cứu hỗn loạn-kỹ sư. Vì vậy, nếu chúng ta nói rằng hoạt động của một hệ thống phức tạp được xác định bởi sự tương tác giữa các bộ phận của nó, thì chúng ta nên quan tâm đến điều gì? Sự tương tác.
Có hai phát hiện thú vị hơn.
Đầu tiên, chúng ta hiểu rằng không thể đơn giản hóa một hệ thống phức tạp bằng cách đơn giản hóa các phần của nó. Thứ hai, cách duy nhất để đơn giản hóa một hệ thống phức tạp là đơn giản hóa sự tương tác giữa các bộ phận của nó.
Chúng ta tương tác như thế nào? Bạn và tôi đều là những bộ phận của một hệ thống thông tin rộng lớn được gọi là xã hội loài người. Chúng ta tương tác thông qua một ngôn ngữ chung, nếu chúng ta có nó, nếu chúng ta tìm thấy nó.
Nhưng bản thân ngôn ngữ là một hệ thống thích ứng phức tạp. Theo đó, để tương tác hiệu quả và đơn giản hơn, chúng ta cần tạo ra một số loại giao thức. Đó là, một số chuỗi ký hiệu và hành động sẽ làm cho việc trao đổi thông tin giữa chúng ta trở nên đơn giản hơn, dễ đoán hơn, dễ hiểu hơn.
Tôi muốn nói rằng các xu hướng hướng tới sự phức tạp, hướng tới khả năng thích ứng, hướng tới sự phân cấp, hướng tới sự hỗn loạn có thể bắt nguồn từ mọi thứ. Và trong những hệ thống mà bạn và tôi đang xây dựng, và trong những hệ thống mà chúng ta là một phần trong đó.
Và không phải là không có cơ sở, hãy xem các hệ thống mà chúng ta tạo ra đang thay đổi như thế nào.
Bạn đang chờ đợi từ này, tôi hiểu. Chúng tôi đang tham dự một hội nghị DevOps, hôm nay từ này sẽ được nghe khoảng một trăm nghìn lần và sau đó chúng tôi sẽ mơ về nó hàng đêm.
Microservice là kiến trúc phần mềm đầu tiên nổi lên như một phản ứng đối với các phương pháp thực hành DevOps, được thiết kế để làm cho hệ thống của chúng tôi linh hoạt hơn, có khả năng mở rộng hơn và đảm bảo phân phối liên tục. Cô ấy làm điều này bằng cách nào? Bằng cách giảm khối lượng dịch vụ, giảm phạm vi vấn đề mà các dịch vụ này xử lý, giảm thời gian giao hàng. Nghĩa là, chúng ta giảm bớt và đơn giản hóa các phần của hệ thống, tăng số lượng của chúng và theo đó, độ phức tạp của các tương tác giữa các phần này luôn tăng lên, tức là các vấn đề mới nảy sinh mà chúng ta phải giải quyết.
Microservices không phải là kết thúc, microservice nói chung đã là ngày hôm qua vì Serverless sắp ra mắt. Tất cả các máy chủ đều bị cháy, không có máy chủ, không có hệ điều hành, chỉ có mã thực thi thuần túy. Cấu hình riêng biệt, trạng thái riêng biệt, mọi thứ đều được kiểm soát bởi các sự kiện. Vẻ đẹp, sự sạch sẽ, sự im lặng, không có sự kiện, không có gì xảy ra, trật tự hoàn toàn.
Đâu là sự phức tạp? Tất nhiên, khó khăn nằm ở sự tương tác. Một chức năng có thể tự làm được bao nhiêu? Nó tương tác với các chức năng khác như thế nào? Hàng đợi tin nhắn, cơ sở dữ liệu, bộ cân bằng. Làm cách nào để tạo lại một số sự kiện khi xảy ra lỗi? Rất nhiều câu hỏi và ít câu trả lời.
Microservices và Serverless là những gì mà những người đam mê hipster chúng tôi gọi là Cloud Native. Đó là tất cả về đám mây. Nhưng đám mây vốn cũng bị hạn chế về khả năng mở rộng. Chúng ta đã quen nghĩ về nó như một hệ thống phân tán. Trên thực tế, máy chủ của nhà cung cấp đám mây đặt ở đâu? Trong các trung tâm dữ liệu. Nghĩa là, chúng ta có một loại mô hình phân tán, tập trung, rất hạn chế ở đây.
Ngày nay chúng ta hiểu rằng Internet of Things không còn chỉ là những lời nói hoa mỹ mà ngay cả theo những dự đoán khiêm tốn nhất, hàng tỷ thiết bị kết nối Internet đang chờ đợi chúng ta trong vòng XNUMX đến XNUMX năm tới. Một lượng lớn dữ liệu hữu ích và vô dụng sẽ được hợp nhất vào đám mây và tải lên từ đám mây.
Đám mây sẽ không tồn tại lâu, vì vậy chúng ta đang ngày càng nói nhiều về thứ gọi là điện toán ranh giới. Hoặc tôi cũng thích định nghĩa tuyệt vời về “điện toán sương mù”. Nó được bao phủ trong sự huyền bí của chủ nghĩa lãng mạn và bí ẩn.
Điện toán sương mù. Vấn đề là các đám mây là những khối nước, hơi nước, băng và đá tập trung. Và sương mù là những giọt nước rải rác xung quanh chúng ta trong bầu khí quyển.
Trong mô hình sương mù, hầu hết công việc được thực hiện bởi những giọt này hoàn toàn tự động hoặc phối hợp với các giọt khác. Và họ chỉ chuyển sang đám mây khi thực sự bị áp lực.
Đó là, một lần nữa là phân quyền, tự chủ, và tất nhiên, nhiều bạn đã hiểu tất cả những điều này sẽ đi đến đâu, bởi vì bạn không thể nói về phân cấp mà không đề cập đến blockchain.
Có những người tin tưởng, đây là những người đã đầu tư vào tiền điện tử. Có những người tin nhưng lại sợ, như tôi chẳng hạn. Và có những người không tin. Ở đây bạn có thể đối xử khác nhau. Có công nghệ, có vấn đề mới chưa biết, có vấn đề. Giống như bất kỳ công nghệ mới nào, nó đặt ra nhiều câu hỏi hơn là câu trả lời.
Sự cường điệu xung quanh blockchain là điều dễ hiểu. Gạt cơn sốt vàng sang một bên, bản thân công nghệ này hứa hẹn những hứa hẹn đáng chú ý về một tương lai tươi sáng hơn: nhiều tự do hơn, nhiều quyền tự chủ hơn, niềm tin toàn cầu được phân tán. Điều gì không muốn?
Theo đó, ngày càng có nhiều kỹ sư trên khắp thế giới bắt đầu phát triển các ứng dụng phi tập trung. Và đây là một sức mạnh không thể bị bác bỏ chỉ bằng cách nói: “À, blockchain chỉ là một cơ sở dữ liệu phân tán được triển khai kém.” Hay như những người hoài nghi muốn nói: “Không có ứng dụng thực sự nào cho blockchain”. Nếu bạn nghĩ về điều đó, 150 năm trước họ cũng nói điều tương tự về điện. Và họ thậm chí còn đúng ở một số khía cạnh, bởi vì những gì điện có thể tạo ra ngày nay là điều không thể thực hiện được ở thế kỷ 19.
Nhân tiện, ai biết được loại logo nào trên màn hình? Đây là Hyperledger. Đây là một dự án đang được phát triển dưới sự bảo trợ của Quỹ Linux và bao gồm một bộ công nghệ blockchain. Đây thực sự là sức mạnh của cộng đồng nguồn mở của chúng tôi.
Kỹ thuật hỗn loạn
Vì vậy, hệ thống mà chúng tôi đang phát triển ngày càng trở nên phức tạp hơn, ngày càng hỗn loạn hơn và ngày càng thích ứng hơn. Netflix là những người tiên phong về hệ thống microservice. Họ là một trong những người đầu tiên hiểu được điều này, họ đã phát triển một bộ công cụ mà họ gọi là Quân đội Simian, trong đó nổi tiếng nhất là . Ông đã định nghĩa cái được gọi là .
Nhân tiện, trong quá trình thực hiện báo cáo, chúng tôi thậm chí còn dịch văn bản này sang tiếng Nga, vì vậy hãy truy cập , đọc, bình luận, mắng mỏ.
Tóm lại, các nguyên tắc của kỹ thuật hỗn loạn nói như sau. Các hệ thống phân tán phức tạp vốn không thể đoán trước được và vốn có nhiều lỗi. Sai sót là không thể tránh khỏi, có nghĩa là chúng ta cần chấp nhận những sai sót này và làm việc với các hệ thống này theo một cách hoàn toàn khác.
Bản thân chúng ta phải cố gắng đưa những lỗi này vào hệ thống sản xuất của mình để kiểm tra hệ thống của chúng ta về khả năng thích ứng tương tự, khả năng tự tổ chức và khả năng sinh tồn này.
Và điều đó thay đổi mọi thứ. Không chỉ cách chúng tôi đưa hệ thống vào sản xuất mà còn cả cách chúng tôi phát triển chúng, cách chúng tôi thử nghiệm chúng. Không có quá trình ổn định hoặc đóng băng mã, trái lại, có một quá trình mất ổn định liên tục. Chúng tôi đang cố gắng tiêu diệt hệ thống và mong muốn nó tiếp tục tồn tại.
Giao thức tích hợp hệ thống phân tán
Theo đó, điều này đòi hỏi hệ thống của chúng tôi phải thay đổi bằng cách nào đó. Để chúng trở nên ổn định hơn, chúng cần một số giao thức mới để tương tác giữa các bộ phận của chúng. Để các bộ phận này có thể đồng ý và đi đến một hình thức tự tổ chức nào đó. Và tất cả các loại công cụ mới, giao thức mới xuất hiện, mà tôi gọi là “giao thức cho sự tương tác của các hệ thống phân tán”.
Tôi đang nói về cái gì vậy? Đầu tiên, dự án . Một số cố gắng tạo ra một giao thức theo dõi phân tán chung, đây là một công cụ hoàn toàn không thể thiếu để gỡ lỗi các hệ thống phân tán phức tạp.
Hơn nữa - . Chúng ta nói rằng chúng ta không thể đoán trước được điều gì sẽ xảy ra với hệ thống, tức là chúng ta cần tăng khả năng quan sát, khả năng quan sát của nó. Opentracing thuộc nhóm công cụ mang lại khả năng quan sát cho hệ thống của chúng tôi. Nhưng chúng ta cần khả năng quan sát để xác định xem hệ thống có hoạt động như chúng ta mong đợi hay không. Làm thế nào để chúng ta xác định hành vi dự kiến? Bằng cách xác định một số loại chính sách, một số quy tắc. Dự án Tác nhân chính sách mở được dành riêng để xác định bộ quy tắc này trên phạm vi từ quyền truy cập đến phân bổ tài nguyên.
Như chúng tôi đã nói, hệ thống của chúng tôi ngày càng hướng tới sự kiện. Serverless là một ví dụ tuyệt vời về hệ thống hướng sự kiện. Để chúng ta chuyển các sự kiện giữa các hệ thống và theo dõi chúng, chúng ta cần một số ngôn ngữ chung, một số giao thức chung về cách chúng ta nói về các sự kiện, cách chúng ta truyền chúng cho nhau. Đây là những gì một dự án được gọi là .
Dòng thay đổi liên tục tràn qua hệ thống của chúng tôi, liên tục làm chúng mất ổn định, là dòng liên tục của các tạo phẩm phần mềm. Để duy trì luồng thay đổi liên tục này, chúng tôi cần một số loại giao thức chung mà qua đó chúng tôi có thể nói về tạo phẩm phần mềm là gì, nó được kiểm tra như thế nào, nó đã vượt qua xác minh nào. Đây là những gì một dự án được gọi là . Đó là một giao thức siêu dữ liệu chung cho các tạo phẩm phần mềm.
Và cuối cùng, nếu chúng ta muốn hệ thống của mình hoàn toàn độc lập, thích ứng và tự tổ chức, chúng ta phải cấp cho chúng quyền tự nhận dạng. Dự án được gọi là Đây chính xác là những gì anh ấy làm. Đây cũng là dự án dưới sự bảo trợ của Cloud Native Computing Foundation.
Tất cả những dự án này đều còn non trẻ, chúng đều cần tình yêu và sự xác nhận của chúng ta. Đây hoàn toàn là nguồn mở, là thử nghiệm, triển khai của chúng tôi. Chúng cho chúng ta thấy công nghệ đang hướng tới đâu.
Nhưng DevOps chưa bao giờ chủ yếu tập trung vào công nghệ mà luôn là sự hợp tác giữa con người với nhau. Và theo đó, nếu chúng ta muốn hệ thống mà chúng ta phát triển thay đổi thì bản thân chúng ta cũng phải thay đổi. Trên thực tế, dù sao thì chúng ta cũng đang thay đổi; chúng ta không có nhiều lựa chọn.
Có một điều tuyệt vời Nhà văn người Anh Rachel Botsman, trong đó bà viết về sự phát triển của niềm tin trong suốt lịch sử loài người. Cô ấy nói rằng ban đầu, trong các xã hội nguyên thủy, niềm tin mang tính địa phương, nghĩa là chúng ta chỉ tin tưởng những người mà chúng ta biết rõ về mặt cá nhân.
Sau đó là một khoảng thời gian rất dài - thời kỳ đen tối khi lòng tin được tập trung hóa, khi chúng ta bắt đầu tin tưởng những người mà chúng ta không quen biết trên cơ sở thực tế là chúng ta thuộc cùng một tổ chức công hoặc nhà nước.
Và đây là những gì chúng ta thấy trong thế giới hiện đại của chúng ta: niềm tin ngày càng trở nên phân tán và phi tập trung hơn, và nó dựa trên sự tự do của các luồng thông tin, vào sự sẵn có của thông tin.
Nếu bạn nghĩ về điều đó, chính khả năng tiếp cận này, điều khiến cho sự tin tưởng này trở nên khả thi, chính là điều mà bạn và tôi đang thực hiện. Điều này có nghĩa là cả cách chúng ta cộng tác và cách chúng ta thực hiện đều phải thay đổi, bởi vì các tổ chức CNTT phân cấp, tập trung ngày xưa không còn hoạt động nữa. Họ bắt đầu chết đi.
Nguyên tắc cơ bản của tổ chức DevOps
Tổ chức DevOps lý tưởng trong tương lai là một hệ thống phi tập trung, thích ứng bao gồm các nhóm tự trị, mỗi nhóm bao gồm các cá nhân tự chủ. Các nhóm này nằm rải rác trên khắp thế giới, cộng tác hiệu quả với nhau bằng cách sử dụng giao tiếp không đồng bộ, sử dụng các giao thức giao tiếp có tính minh bạch cao. Rất đẹp phải không? Một tương lai rất tươi đẹp.
Tất nhiên, không điều nào có thể thực hiện được nếu không có sự thay đổi về văn hóa. Chúng ta phải có sự lãnh đạo mang tính chuyển đổi, trách nhiệm cá nhân, động lực nội tại.
Đây là nền tảng của các tổ chức DevOps: minh bạch thông tin, truyền thông không đồng bộ, lãnh đạo chuyển đổi, phân quyền.
Kiệt sức
Các hệ thống mà chúng ta là một phần và những hệ thống mà chúng ta xây dựng ngày càng hỗn loạn, và con người chúng ta khó có thể đương đầu với suy nghĩ này, rất khó để từ bỏ ảo tưởng về khả năng kiểm soát. Chúng ta cố gắng tiếp tục kiểm soát chúng và điều này thường dẫn đến kiệt sức. Tôi nói điều này từ kinh nghiệm của bản thân, tôi cũng bị bỏng, tôi cũng bị tàn tật bởi những thất bại không lường trước được trong quá trình sản xuất.
Sự kiệt sức xảy ra khi chúng ta cố gắng kiểm soát thứ gì đó vốn dĩ không thể kiểm soát được. Khi chúng ta kiệt sức, mọi thứ sẽ mất đi ý nghĩa vì chúng ta mất đi ham muốn làm điều gì đó mới, chúng ta trở nên phòng thủ và bắt đầu bảo vệ những gì mình có.
Nghề kỹ sư, như tôi thường tự nhắc nhở mình, trước hết là một nghề sáng tạo. Nếu chúng ta mất đi ham muốn tạo ra một cái gì đó thì chúng ta sẽ biến thành tro bụi, biến thành tro bụi. Mọi người kiệt sức, toàn bộ tổ chức kiệt sức.
Theo tôi, chỉ chấp nhận sức mạnh sáng tạo của sự hỗn loạn, chỉ xây dựng sự hợp tác theo nguyên tắc của nó mới là điều sẽ giúp chúng ta không đánh mất những gì tốt đẹp trong nghề của mình.
Đây là điều tôi mong muốn ở bạn: yêu công việc của bạn, yêu những gì chúng tôi làm. Thế giới này được nuôi dưỡng bằng thông tin, chúng ta có vinh dự được nuôi dưỡng nó. Vì vậy, hãy nghiên cứu về sự hỗn loạn, hãy trở thành nhà nghiên cứu về hỗn loạn, hãy mang lại giá trị, tạo ra thứ gì đó mới, à, các vấn đề, như chúng ta đã phát hiện ra, là không thể tránh khỏi, và khi chúng xuất hiện, chúng ta sẽ chỉ nói “Ops!” Và vấn đề được giải quyết.
Còn gì khác ngoài Chaos Monkey?
Trên thực tế, tất cả những nhạc cụ này đều còn rất trẻ. Netflix cũng tự xây dựng các công cụ cho riêng mình. Xây dựng công cụ của riêng bạn. Đọc các nguyên tắc của kỹ thuật hỗn loạn và tuân theo những nguyên tắc đó thay vì cố gắng tìm những công cụ khác mà người khác đã chế tạo.
Hãy cố gắng hiểu hệ thống của bạn bị hỏng như thế nào và bắt đầu phá vỡ chúng và xem chúng tồn tại như thế nào. Điều này đến trước tiên. Và bạn có thể tìm kiếm các công cụ. Có đủ loại dự án.
Tôi không hiểu lắm khi bạn nói rằng hệ thống không thể được đơn giản hóa bằng cách đơn giản hóa các thành phần của nó và ngay lập tức chuyển sang microservice, giúp đơn giản hóa hệ thống bằng cách đơn giản hóa chính các thành phần và làm phức tạp các tương tác. Về cơ bản đây là hai phần mâu thuẫn với nhau.
Đúng vậy, microservice nói chung là một chủ đề gây tranh cãi rất nhiều. Trên thực tế, việc đơn giản hóa các bộ phận sẽ làm tăng tính linh hoạt. Microservice cung cấp những gì? Chúng mang lại cho chúng ta sự linh hoạt và tốc độ, nhưng chắc chắn chúng không mang lại cho chúng ta sự đơn giản. Họ tăng độ khó.
Vậy, trong triết lý DevOps, microservice không phải là một điều tốt?
Cái tốt nào cũng có mặt trái của nó. Lợi ích là nó tăng tính linh hoạt, cho phép chúng ta thực hiện các thay đổi nhanh hơn, nhưng nó làm tăng độ phức tạp và do đó làm tăng tính dễ vỡ của toàn bộ hệ thống.
Tuy nhiên, điều gì được nhấn mạnh hơn: đơn giản hóa sự tương tác hay đơn giản hóa các bộ phận?
Tất nhiên, trọng tâm là đơn giản hóa các tương tác, bởi vì nếu chúng ta nhìn điều này từ quan điểm cách chúng tôi làm việc với bạn, thì trước hết, chúng tôi cần chú ý đến việc đơn giản hóa các tương tác chứ không phải đơn giản hóa công việc. riêng biệt của mỗi chúng ta. Bởi đơn giản hóa công việc đồng nghĩa với việc biến thành robot. Ở McDonald's, mọi chuyện hoạt động bình thường khi bạn có hướng dẫn: đây bạn đặt bánh mì kẹp thịt, đây bạn đổ nước sốt lên. Điều này hoàn toàn không có tác dụng trong công việc sáng tạo của chúng tôi.
Có đúng là tất cả những gì bạn nói đều sống trong một thế giới không có sự cạnh tranh, và sự hỗn loạn ở đó rất tử tế, và không có mâu thuẫn trong sự hỗn loạn này, không ai muốn ăn thịt hay giết ai? Sự cạnh tranh và DevOps sẽ diễn ra như thế nào?
Vâng, nó phụ thuộc vào loại cạnh tranh mà chúng ta đang nói đến. Đó là về sự cạnh tranh ở nơi làm việc hay sự cạnh tranh giữa các công ty?
Về sự cạnh tranh của các dịch vụ tồn tại vì dịch vụ không phải là một số công ty. Chúng ta đang tạo ra một loại môi trường thông tin mới và bất kỳ môi trường nào cũng không thể tồn tại nếu không có cạnh tranh. Có sự cạnh tranh ở khắp mọi nơi.
Netflix giống nhau, chúng tôi lấy họ làm hình mẫu. Tại sao họ nghĩ ra điều này? Bởi vì họ cần phải cạnh tranh. Tính linh hoạt và tốc độ di chuyển này chính xác là yêu cầu mang tính cạnh tranh cao; nó đưa sự hỗn loạn vào hệ thống của chúng ta. Nghĩa là, hỗn loạn không phải là điều chúng ta cố ý làm vì chúng ta muốn nó, mà là điều xảy ra vì thế giới yêu cầu điều đó. Chúng ta chỉ cần thích nghi. Và sự hỗn loạn, đó chính xác là kết quả của sự cạnh tranh.
Phải chăng điều này có nghĩa là sự hỗn loạn là sự thiếu vắng các mục tiêu? Hay những mục tiêu mà chúng ta không muốn thấy? Chúng ta đang ở trong nhà và không hiểu mục đích của người khác. Trên thực tế, cạnh tranh là do chúng ta có mục tiêu rõ ràng và chúng ta biết mình sẽ đạt đến đâu vào mỗi thời điểm tiếp theo. Theo quan điểm của tôi, đây là bản chất của DevOps.
Ngoài ra một cái nhìn vào câu hỏi. Tôi nghĩ tất cả chúng ta đều có cùng một mục tiêu: tồn tại và làm điều đó với
niềm vui lớn nhất. Và mục tiêu cạnh tranh của bất kỳ tổ chức nào cũng giống nhau. Sự sống còn thường xảy ra thông qua cạnh tranh, bạn không thể làm gì được.
Hội nghị năm nay sẽ diễn ra vào ngày 7 tháng 11 tại Technopolis. Chúng tôi đang chấp nhận đơn đăng ký báo cáo cho đến ngày XNUMX tháng XNUMX. chúng tôi nếu bạn muốn nói chuyện.
Mở đăng ký cho người tham gia, vé có giá 7000 rúp. Tham gia với chúng tôi!
Nguồn: www.habr.com