Thích ứng với mô hình điều hành cloud Phần 1: Lấy tốc độ làm động lực kinh doanh

Thu HaTr

1.jpg
Mọi doanh nghiệp hiện này đều đang trở thành công ty công nghệ. Điều này đã từng được khẳng định . Công nghệ chính là cách duy nhất để duy trì tính cạnh tranh trong bối cảnh hiện nay. Đối với một số doanh nghiệp, điều này có nghĩa là phải bắt kịp công nghệ, nâng tầm công nghệ cho doanh nghiệp của mình. Và cách để trở thành một công ty công nghệ là cung cấp phần mềm — như MarcAndreesen đã phát biểu nổi tiếng gần một thập kỷ trước, Phần mềm đang “ăn” cả thế giới .  

Phân phối phần mềm đã trải qua quá trình chuyển đổi riêng trong những năm gần đây với sự gia tăng của cloud computing. Điều đã từng kéo dài nhiều năm, các dự án thác nước để phát triển và đóng gói phần mềm cho các bản phát hành chính giờ đây là một dòng cập nhật liên tục, nhanh nhẹn. Tương tự, những gì đã từng được sửa. trung tâm dữ liệu của máy chủ tĩnh hiện là môi trường cloud động với các nguồn tài nguyên linh hoạt trên các nhà cung cấp IaaS như Amazon Web Services (AWS), Google Cloud Platform (GCP) và Microsoft Azure.

Chủ đề cơ bản đằng sau việc cung cấp phần mềm và cung cấp cơ sở hạ tầng trên cloud là tốc độ. Áp lực cạnh tranh và tăng trưởng đều đòi hỏi điều đó. Các doanh nghiệp phải cung cấp sự đổi mới liên tục cho khách hàng của họ, có nghĩa là các nhà phát triển phải cung cấp sự đổi mới liên tục cho doanh nghiệp — tất cả đều dưới hình thức phần mềm.
Trong chu kỳ linh hoạt này, tốc độ trên quy mô nổi lên như động lực kinh doanh và kỹ thuật chính, với các chương trình DevOps là tác nhân của sự thay đổi và phương pháp đạt được thành tích. Mọi công ty đều cố gắng làm nhiều hơn với ít hơn, có nghĩa là hợp lý hóa càng nhiều cải tiến kỹ thuật số và cải tiến quy trình. Do đó, các nhóm CNTT và Bảo mật đang dần trở thành những người hỗ trợ kinh doanh. Bạn muốn trở thành người hùng tại công ty của mình? Hãy đón nhận sự thay đổi này. Bạn muốn trở thành người lãnh đạo tại công ty của mình? Hãy trao quyền cho các team.  

Mô hình điều hành cloud là gì?
Để hiểu mô hình này, trước tiên hãy nhìn vào mô hình hoạt động truyền thống. Trước khi cloud ra đời, các công ty sẽ chi một lượng lớn vốn đầu tư cho không gian trung tâm dữ liệu. Các môi trường này thường đã được cố định, với kích thước lớn nhằm có lưu lượng truy cập cao nhất trong năm. Các máy chủ trong các trung tâm dữ liệu này có thể tồn tại trong nhiều năm, chỉ setup cấu hình một lần và cập nhật không thường xuyên. Bất kỳ thay đổi nào đối với những môi trường này sẽ phải trải qua một quá trình rấtdài, khó khăn và gian khổ.
Cloud đã thay đổi tất cả những điều này. Các công ty hiện có thể sử dụng một loạt các tài nguyên máy tính, lưu trữ và networking với chi phí hợp lý nhất có thể (dùng bao nhiêu trả bấy nhiêu). Môi trường cloud luôn linh hoạt, với các nguồn lực đàn hồi xoay chuyển lên xuống, thích ứng theo thời gian thực. Các tài nguyên là bất biến và chỉ tồn tại trong vài tuần, vài ngày, vài giờ hoặc thậm chí vài phút. Môi trường được định cấu hình thông qua các công cụ tự động hóa và workflow, với bất kỳ thay đổi nào sẽ được thông báo và thực hiện ngay lặp tức.
2.png

Yêu cầu về tốc độ ở quy mô lớn chỉ có thể được thực hiện bằng cách nắm bắt hoàn toàn cloud, nhưng nó không hề dễ dàng. Với sự thay đổi đáng kể về các đặc điểm và hành vi môi trường, kiến trúc cơ bản phải có khả năng thích ứng. Mô hình điều hành cloud - một khuôn khổ chiến lược để áp dụng cloud được thúc đẩy bởi văn hóa tự động hóa DevOps tác động đến con người, quy trình và công nghệ.
Bồi dưỡng văn hóa tự động hóa
Bất kỳ tác nhân thay đổi nào cũng cần được doanh nghiệp ban phước để nó thành công, đặc biệt là những tác nhân bao gồm các nhóm chức năng chéo. Nhưng không thể đơn giản tuyên bố văn hóa và gọi nó là Các chương trình DevOps trưởng thành đến từ các doanh nghiệp trao quyền cho nhóm của họ vì đó là khi văn hóa có thể thực sự xuất hiện. Một chiến thắng; cần có sự thống nhất về mục tiêu chung, trách nhiệm chung và trách nhiệm chung.
3.png
Con người, quy trình và công nghệ của một chương trình DevOps trưởng thành được bao bọc trong tự động hóa, với tính năng bảo mật được nhúng ngay từ đầu. Các nhóm tự doanh nghiệp triển khai các công cụ tự phục vụ để hợp lý hóa việc phân phối và triển khai phần mềm cũng như cung cấp và cấu hình cơ sở hạ tầng Một lý do chính khi việc áp dụng cloud yêu cầu thay đổi mô hình hoạt động là loại bỏ bất kỳ rào cản nào khỏi quá trình tự động hóa này một cách an toàn. Mô hình hoạt động truyền thống vừa là yếu tố cản trở tự động hóa vừa là rủi ro đối với bảo mật, điều này có hại cho kết quả kinh doanh của vận tốc.
Vì tốc độ có thể được định lượng, các nhà lãnh đạo doanh nghiệp đứng sau sự thay đổi này sẽ mong đợi kết quả. Và khi tốc độ là kết quả, thì kỳ vọng về thời điểm nó xảy ra là… nhanh. Các chỉ số chính mà một chương trình DevOps được đo lường liên quan đến phần mềm phát triển và phân phối, trong khi các hoạt động cơ bản và các chức năng bảo mật đóng vai trò là nhóm phụ (nhưng hầu như không được chú ý).
Nhóm Nghiên cứu & Đánh giá DevOps (DORA), hiện là một bộ phận của Google, nhận thấy các chỉ số sau quan trọng nhất để các doanh nghiệp đo lường:  
  • Tần suất triển khai : Doanh nghiệp của bạn triển khai mã để sản xuất hoặc phát hành mã cho người dùng cuối bao lâu một lần ? ( Hiệu suất cao: từ một lần mỗi ngày đến một lần mỗi tuần )
  • Thời gian thực hiện các thay đổi : Mất bao lâu để từ khi mã được cam kết đến khi mã chạy thành công trong phiên bản sản xuất? (Người hoạt động tốt: từ một ngày đến một tuần )
  • Thời gian khôi phục dịch vụ : Thường mất bao lâu để khôi phục dịch vụ khi xảy ra sự cố hoặc lỗi dịch vụ ảnh hưởng đến người dùng? (Người hoạt động tốt: dưới một ngày )
  • Tỷ lệ lỗi thay đổi : Tỷ lệ thay đổi đối với sản xuất hoặc bản phát hành cho người dùng dẫn đến dịch vụ bị xuống cấp và sau đó yêu cầu sửa chữa? ( Hiệu suất cao: 0-15% )

4.png

Nguồn: Báo cáo trạng thái DevOps của Cơ quan Nghiên cứu DevOps (DORA) năm 2019 
Với thông lượng và độ ổn định là các chỉ số hàng đầu cho hiệu suất của Dev, điều đó sẽ không còn hoạt động nào nữa của ngôi nhà? Chức năng DevOps không kết thúc khi phần mềm ra mắt; cần có nỗ lực phối hợp để giữ cho hệ thống và ứng dụng hoạt động tốt. là ba từ được quan tâm hàng đầu đối với bất kỳ ai chịu trách nhiệm vận hành cơ sở hạ tầng cloud — tính khả dụng, khả năng phục hồi và bảo mật. Mặc dù các thuộc tính này theo truyền thống có tính chất bảo vệ nhanh chóng, nhưng các doanh nghiệp có chương trình DevOps trưởng thành lại thấy chúng luôn song hành với nhau . Các hệ thống khả dụng cao cho phép thông lượng tốt hơn và các hệ thống đàn hồi tốt hơn cho phép ổn định.
Được Google phổ biến, vai trò Kỹ thuật độ tin cậy của trang web (SRE) bổ sung cho các chương trình DevOps bằng cách nắm quyền sở hữu số liệu quan trọng nhất trong số đó — thời gian hoạt động. Bất kỳ công ty nào cung cấp phần mềm dưới dạng dịch vụ đều đặt danh tiếng của họ lên hàng đầu với Thỏa thuận mức dịch vụ (SLA) của họ ); chúng tôi làm ở Okta với 99,99% SLA thời gian hoạt động của chúng tôi (nhân tiện, điều đó rất tốt).  
Là một chức năng kỹ thuật, SRE không ngừng theo dõi và cải tiến các hệ thống và quy trình để giảm thiểu hai chỉ số chính:
  • Thời gian trung bình để xác nhận (MTTA) : Mất bao lâu để bắt đầu giải quyết một vấn đề sau khi cảnh báo được kích hoạt? (Người hoạt động tốt: dưới 5 phút )
  • Thời gian trung bình để giải quyết (MTTR) : Mất bao lâu để giải quyết sự cố ngừng hoạt động và khôi phục dịch vụ cho khách hàng? ( Hiệu suất cao: dưới 1 giờ )
Bản chất năng động của cloud với tốc độ không đổi khiến công việc này trở thành một công việc khó khăn. Các công ty có chương trình DevOps trưởng thành gắn kết các chỉ số SRE với doanh nghiệp — xét cho cùng, thời gian hoạt động là một lợi thế cạnh tranh. Công việc kỹ thuật cốt lõi của nhóm SRE là Bạn càng chủ động với các nút thắt cổ chai, rào cản và sự cố tiềm ẩn thì càng tốt. Xây dựng khả năng quan sát trong toàn bộ hệ thống công nghệ và trong mọi quy trình tự động.

Khâu nó lại với nhau
Một chương trình phát triển, phân phối và triển khai phần mềm hoàn toàn tự động không chỉ diễn ra trong một sớm một chiều. Trừ khi doanh nghiệp của bạn bắt đầu vào ngày hôm qua, bạn sẽ có nợ kỹ thuật để hiện đại hóa và các quy trình để hợp lý hóa. DevOps là sự thống nhất giữa hoạt động phát triển phần mềm và cơ sở hạ tầng mang những vai trò và trách nhiệm độc lập của riêng họ. Sự trưởng thành được xác định bằng cách tt cả kết hợp với nhau một cách hiệu quả.
Sự kém hiệu quả tồn tại khi các chức năng này rời rạc. Các nhà phát triển viết mã riêng biệt và sau đó "ném nó qua tường" để các nhóm vận hành triển khai. Ngoài việc có các định nghĩa khác nhau về việc hoàn thành, điều này luôn dẫn ến việc chỉ tay khi có sự cố. Sự nổi tiếng , "Nó đã hoạt động trên máy của tôi" bắt nguồn từ sự xuất hiện này.
5.png
Sự gia tăng của các công cụ cộng tác và sự ra đời của công nghệ ảo hóa trên cloud đã giúp thu hẹp khoảng cách này. Với Máy ảo và Vùng chứa, môi trường thời gian chạy cục bộ có thể phản ánh chặt chẽ môi trường sản xuất. Các quy trình phát triển và phân phối phần mềm diễn ra thông qua các hành động theo hướng sự kiện được kết nối với nguồn kiểm soát, phổ biến nhất là Git. Các điểm kiểm tra khác nhau dọc theo đường ống Tích hợp liên tục và Triển khai liên tục (CI / CD) này cho phép cộng tác tốt hơn (và ít bị chỉ tay hơn).
6.png
Mặc dù hình ảnh trên là một cải tiến đáng kể so với cách tiếp cận cũ, nhưng vẫn còn nhiều điều mong muốn. Nhóm Phát triển và Vận hành có thể vẫn bị ngắt kết nối và các trạm kiểm soát có thể vẫn chứa các quy trình thủ công, nặng nề. Trạng thái "chén thánh" là Tự động hóa hoàn toàn mọi thứ theo một chu kỳ liên tục. Điều mà doanh nghiệp thực sự muốn là các nhà phát triển chỉ viết mã và các hoạt động chỉ tối ưu hóa hiệu suất. Nghe như một giấc mơ.   
7.png
Như với bất kỳ trạng thái lý tưởng nào, thực tế nhanh chóng bắt đầu và quan điểm về một chu kỳ liên tục của tự động hóa và cộng tác có vẻ nằm ngoài tầm với… và nguy hiểm. Nhưng không có gì sai khi phấn đấu đạt được “chén thánh” nếu bạn thực hiện các bước gia tăng đúng đắn Nói cách khác — Indiana Jones sẽ trở thành một nhà lãnh đạo DevOps tuyệt vời. Để đến đó và tiến hành một cách thận trọng, thay vì nhắm đến trạng thái cuối một cách mù quáng mà không cân nhắc.

Sự cân bằng giữa năng suất và an ninh
Trong các bài đăng tiếp theo của loạt bài này, chúng ta sẽ thảo luận chi tiết về hành trình này. Tôi sẽ kết thúc bài đăng đầu tiên với điều này — thực hiện mọi thứ một cách thành công thường có nghĩa là tiếp cận các sáng kiến và thách thức với một tư duy cân bằng. Điều hành Cloud Mô hình như chúng ta vừa thảo luận có nghĩa là cân bằng giữa năng suất và bảo mật . Hay như tôi muốn nói, “Di chuyển nhanh chóng mà không phá vỡ mọi thứ.” Nhìn chung, có hai quan điểm liên quan đến năng suất và bảo mật:   
  • Năng suất mà không ảnh hưởng đến bảo mật là quan điểm lấy người dùng làm trung tâm, hết sức lưu ý rằng việc tự động hóa đang được xây dựng là yếu tố cần cân nhắc về bảo mật trước khi triển khai trực tiếp trong sản xuất. 
  • Bảo mật mà không ảnh hưởng đến năng suất là quan điểm tập trung vào hoạt động, cần hết sức lưu ý rằng các chính sách và thủ tục cần thiết để đáp ứng các nguyên tắc tuân thủ sẽ không cản trở quá trình tự động hóa được xây dựng. 

8.png

Những quan điểm này thực sự là hai mặt của cùng một xu hướng — cho phép vận tốc an toàn trên quy mô lớn . Khi tất cả các chức năng của DevOps được liên kết theo cách này, văn hóa tự động hóa thực sự bắt đầu hình thành, mang lại sự đổi mới liên tục cần thiết cho doanh nghiệp thắng lợi. 

Nguồn: https://dzone.com/articles/adapt-to-the-cloud-operating-model-part-1-velocity
 
Top