Chúng ta đã đi được hơn nửa cuối năm rồi! Cùng với thời gian sẽ thay đổi và cùng với sự thay đổi sẽ xuất hiện những kỹ năng mới để bắt đầu suy nghĩ về nó. Bởi vì bạn không nên quá tải với việc học cả triệu thứ cùng một lúc, tốt hơn hết là bạn nên nghĩ về một năm sẽ như thế nào từ quan điểm học tập cho 4-5 chủ đề.
Không gian công nghệ không phải là một nghề nghiệp mà bạn chỉ có thể học một lần. Thay vào đó, bạn phải nghĩ về cách nâng cao kỹ năng của bản thân hàng tháng. Bạn không cần phải ngồi trong phòng cả ngày với đống code và bỏ bê toàn bộ cuộc sống của mình. Tuy nhiên, bạn phải hiểu những gì đang thay đổi trong không gian công nghệ, những gì bạn có thể làm để làm cho một tổ chức tốt hơn (đặc biệt là vì các kỹ sư hiện là những người ra quyết định) và làm thế nào để duy trì việc làm của bạn bởi vì sự thật của vấn đề là mọi người bị sa thải mọi lúc và không thể tìm được việc làm vì họ không cập nhật kỹ năng của mình.
Trong bài này Wikicode sẽ giúp bạn tìm hiểu về 5 xu hướng mới hàng đầu dành cho DevOps sắp ra mắt và thịnh hành trong các năm tới và tại sao chúng lại quan trọng.
Tự động hóa cơ sở hạ tầng
Mặc dù đã phổ biến, nhưng các phương pháp cơ sở hạ tầng dành riêng cho code và các phương pháp cơ sở hạ tầng dành riêng cho code khác đang ngày càng trở nên phổ biến hơn. Do cách thức của thế giới hiện tại và đã được vài năm, ngày càng nhiều tổ chức đang cố gắng mở rộng quy mô sang đám mây. Cho dù đó là do các văn phòng đóng cửa hay có lẽ đơn giản là việc giữ máy chủ tại chỗ không còn hợp lý nữa, các kỹ sư cần khả năng di chuyển nhanh hơn để di chuyển / mở rộng / tạo lại bất cứ thứ gì đang chạy trên các máy chủ tại chỗ cũ.
Tự động hóa cơ sở hạ tầng là con đường của tương lai đám mây. Có một số công cụ hiện có, nhưng công cụ hoàn toàn ưu tiên hiện nay là HashiCorps Terraform, là một công cụ cơ sở hạ tầng dưới dạng code được viết bằng Ngôn ngữ cấu hình HashiCorp (HCL) để xác định những gì bạn muốn cơ sở hạ tầng đám mây (và tại chỗ) để trông giống như.
Để thực hiện tự động hóa cơ sở hạ tầng, bạn phải:
- Hãy thoải mái viết code. Bạn không cần phải viết Twitter tiếp theo. Đơn giản là bạn phải ổn với việc học cách tự động hóa.
- Một hệ thống kiểm soát nguồn để lưu code vào (như GitHub).
- Giúp doanh nghiệp hiểu rằng mặc dù trong nhiều năm, các kỹ sư cơ sở hạ tầng không phải là lập trình viên, thời gian đang thay đổi và hiện tại là như vậy. Mọi người đều là nhà phát triển trong thế giới ngày nay.
Bảo mật DevOps
An ninh thường là một trong những khía cạnh bị bỏ qua tuyệt đối nhất trong bất kỳ tổ chức nào. Trên thực tế, Gene Kim (nhà nghiên cứu DevOps) đã nói rằng cứ 100 nhà phát triển thì có 1 kỹ sư bảo mật. Khi bạn nghĩ về nó, những con số hoàn toàn đáng sợ. Đặc biệt là xem xét nhiều tổ chức muốn di chuyển nhanh và thực hiện bảo mật sau đó hơn là làm mọi thứ ngay lần đầu tiên.
Tuy nhiên, thời gian đang thay đổi. Nhiều người đang làm việc tại nhà hơn, nhiều dịch vụ hơn đang được chạy trên đám mây và nhiều cuộc tấn công hơn đang xảy ra hàng ngày. Do đó, cách một kỹ sư viết phần mềm phải an toàn, nhưng cách mà phần mềm đó đang được triển khai đến đích của nó cũng phải an toàn (và chính điểm đến).
Để bắt đầu suy nghĩ đúng đắn về bảo mật, bạn phải:
- Hiểu bảo mật là gì. Ví dụ, ý tưởng không phải là loại bỏ tất cả rủi ro, mà là giảm thiểu càng nhiều càng tốt.
- Có sẵn các trình quét lỗ hổng trên đám mây (và tại chỗ) thích hợp để quét bất kỳ dịch vụ nào bạn đang sử dụng.
- Bảo mật mã bạn đang viết (có thể là cơ sở hạ tầng dưới dạng mã) bằng các bài kiểm tra tiêu chuẩn (đơn vị / tích hợp / mô hình / v.v.) và / hoặc Chính sách dưới dạng mã.
Kỹ thuật hỗn loạn
Bạn đã bao giờ thức dậy lúc 2:00 sáng vì một ứng dụng bị lỗi do không thể chịu được một số tải đột xuất? Hoặc có thể RAM trên máy chủ tăng đột biến và gây ra cảnh báo? Ý tưởng đằng sau kỹ thuật hỗn loạn là để ngăn chặn điều này. Một số tổ chức sử dụng nó trước khi một ứng dụng được triển khai và các tổ chức khác tiến thêm một bước nữa và sử dụng nó trong sản xuất.
Đó là một cách tuyệt vời để tìm ra các lỗ hổng từ góc độ bảo mật / lỗ hổng bảo mật và có sự trợ giúp để dự đoán khi nào sự cố hệ thống có thể xảy ra. Toàn bộ ý tưởng đằng sau Chaos Engineering là bạn muốn có khả năng phá vỡ một hệ thống có chủ đích để bạn có thể tìm ra lý do và cách bạn có thể phá vỡ nó, cuối cùng là làm cho hệ thống tốt hơn nhiều.
Một trong những công cụ tốt nhất và thú vị nhất mà bạn có thể xem qua là Chaos Monkey do Netflix tạo ra, đây là một công cụ Chaos Engineering. Vui lòng không sử dụng nó trong hệ thống sản xuất của riêng bạn cho đến khi bạn đã kiểm tra đầy đủ công cụ và ban quản lý có dấu hiệu tắt nó.
Để thực hiện kỹ thuật hỗn loạn thích hợp, bạn phải:
- Hiểu rằng đó là tất cả về cách tìm ra điểm yếu và lỗ hổng trong hệ thống.
- Đặt đường cơ sở cho cách bạn tin rằng hệ thống sẽ hoạt động.
- Rất nhiều thử nghiệm có liên quan. Đó là rất nhiều R & D (Nghiên cứu và Phát triển Kỹ thuật).
Các kỹ sư hiện là người ra quyết định
Không gian công nghệ luôn phát triển và không ngừng thay đổi. Sẽ không bao giờ có cách nào để giải quyết vấn đề đó, vì vậy một điều cần ghi nhớ là bạn phải cảm thấy thoải mái với sự thay đổi và có khả năng thích ứng. Bởi vì các kỹ sư thường là kiểu người tò mò, học hỏi những điều mới rất thoải mái. Tuy nhiên, đối với hầu hết những người làm công tác quản lý, đó có thể không phải là điểm mạnh của họ, đặc biệt nếu họ không có nền tảng kỹ thuật và điều đó hoàn toàn ổn.
Do đó, ban lãnh đạo bắt đầu hiểu rằng họ không thể tự mình nghĩ ra sản phẩm hoặc môi trường trông như thế nào và chuyển nó cho các kỹ sư xây dựng. Thay vào đó, các kỹ sư phải tham gia vào quá trình ra quyết định. Cho dù đó là sử dụng ngôn ngữ lập trình này hay ngôn ngữ lập trình khác cho một ứng dụng hoặc chọn đám mây công cộng nào. Các kỹ sư phải cảm thấy thoải mái khi đội chiếc mũ của người quản lý và đi sâu vào việc ra quyết định.
Loại tư duy này của cả kỹ sư và quản lý sẽ tạo ra một môi trường tuyệt vời và những đổi mới tuyệt vời.
Để có khả năng đưa ra quyết định với tư cách là một kỹ sư, bạn phải:
- Hiểu những gì doanh nghiệp thực sự làm.
- Hiểu tại sao doanh nghiệp làm những gì nó làm.
- Kết hợp khả năng kỹ thuật của bạn với một quy trình suy nghĩ cho phép bạn xem xét các tình huống.
Quản lý dòng giá trị (VSM)
Đo lường giá trị từ một kỹ sư luôn có phần khó khăn. Trong những ngày đầu viết mã, các kỹ sư sẽ nhận được tiền thưởng và lời khen ngợi nếu họ có số lượng dòng mã “X”. Tuy nhiên, thế giới công nghệ nhanh chóng biết được rằng tất cả những gì đã làm là tạo ra nợ kỹ thuật. Kể từ đó, nó là một cuộc chiến liên tục để suy nghĩ về cách đo lường giá trị và quan trọng hơn, giá trị thực sự có ý nghĩa như thế nào.
Với Quản lý dòng giá trị, có rất nhiều cách khác nhau để đo lường giá trị. Ví dụ: bạn có thể xem liệu các đường ống có bị lỗi hay không và tại sao chúng bị lỗi, sau đó xem điều gì khiến chúng không thành công. Sau đó, bạn có thể nhận được số liệu phân tích, tỷ lệ phần trăm và số liệu thống kê của đường dẫn. Sau đó, bạn có thể đo lường giá trị mà bạn đang nhận được từ đường ống dẫn và nếu nó thất bại, nó sẽ không nhiều, vì vậy bạn có thể vào và sửa chữa nó dựa trên mức độ quan trọng của nó.
Cũng có một vài sai lệch so với VSM. Ví dụ: Phân phối dòng giá trị, Phân tích dòng giá trị, v.v. Điều quan trọng là không bị cuốn vào các từ thông dụng. Hiểu rằng đó là tất cả về việc đo lường giá trị.
Để thực hiện một quy trình VSM thích hợp, bạn phải:
- Hiểu rằng “nhiều hơn” không có nghĩa là “nhiều hơn”. Bạn nên luôn nghĩ về chất lượng hơn số lượng. Ví dụ, nếu một kỹ sư tạo ra 10 đường ống, điều đó thật tuyệt, nhưng tất cả những đường ống đó có đi qua không? Có 5 đường ống đang đi qua thay vì 7/10 đường ống bị hỏng thì tốt hơn nhiều.
- Chọn phần mềm mà bạn cảm thấy thoải mái. Có rất nhiều nhà cung cấp trong không gian VSM, nhưng một số làm VSM tốt hơn những nhà cung cấp khác. Ví dụ, một số nhà cung cấp VSM sẽ tập trung nhiều hơn vào hợp tác kỹ thuật và quản lý trong khi những nhà cung cấp khác sẽ tập trung nhiều hơn vào hiệu quả. Ví dụ – nếu đường ống bị hỏng, tại sao?
- Đảm bảo rằng mọi người biết rằng đây không phải là một triển khai quản lý vi mô. Với một số nhà cung cấp VSM, bạn có thể truy cập và xem những kỹ sư nào đang làm việc trên nhánh nào và họ đang đóng góp vào lĩnh vực nào. Điều này có thể trở nên rất “quản lý vi mô” thực sự nhanh chóng, và điều đó đánh bại mục đích của VSM.
Qua đây bạn đã thấy, hiểu và nắm được các kiến thức cơ bản về 5 xu thế mới của DevOps hiện nay mà ban có thể tập trung nghiên cứu sâu hơn để áp dụng nó vào công việc hiện tại của cty và của bạn.
Nếu bạn cảm thấy hữu ích và yêu thích Thế giới JS, hãy tham gia và theo dõi chúng tôi để nhận thêm nhiều kiến thức MIỄN PHÍ hơn nữa nhé:
Share to learn more than!
