Những sai lầm phổ biến cần tránh khi di cư

Đối với các doanh nghiệp, có thể di chuyển hàng nghìn ứng dụng là một phần tất yếu để duy trì tính cạnh tranh. Tìm ra cách để đạt được một cuộc di chuyển thành công là điều đáng sợ, vì vậy chúng ta hãy đi sâu vào những cạm bẫy để tránh.

COVID-19 đã tạo ra cả sự thiếu hụt nhân tài kỹ thuật kết hợp với sự gia tăng nhu cầu về các mốc thời gian kỹ thuật được tăng tốc. Nhiều công ty đang bắt đầu đối mặt với hiệu ứng “ Red Queen ”, nơi các công ty phải xác định lại cách thức và vị trí họ đang cạnh tranh trên thị trường để đảm bảo chúng vẫn phù hợp. Ngày nay, các doanh nghiệp vẫn tự mãn được thưởng bằng một bất lợi khó khăn và một chu kỳ bắt kịp vĩnh viễn. Chuyển đổi từ các công nghệ hiện tại sang các giải pháp hiệu quả hơn và đáp ứng chi phí hiệu quả hơn là một phần quan trọng trong quá trình biến đổi của bất kỳ doanh nghiệp nào; tuy nhiên, nó có thể đầy cạm bẫy cho những người không chuẩn bị.

Theo một nghiên cứu của Boston Consulting Group vào năm 2020, bao gồm 825 giám đốc điều hành cấp cao của 70 công ty liên quan đến 895 chuyển đổi kỹ thuật số, chỉ 30% chuyển đổi đạt được mục tiêu chuyển đổi của họ.

Đó không phải là những con số để truyền cảm hứng cho sự tự tin. May mắn thay, các doanh nghiệp như Stark & Wayne đã làm việc để cho phép nhiều doanh nghiệp di chuyển để những người khác có thể tránh chúng. Stark & Wayne là một chuyên gia trong việc di chuyển cơ sở hạ tầng quy mô doanh nghiệp. Các dự án trước đây đã bao gồm triển khai Cloud Foundry Foundation quản lý 45.000 phiên bản ứng dụng.

Ghi lại Đường cơ sở Hiệu suất

Đó là một nhiệm vụ! Mọi công ty đều yêu cầu hiệu suất tốt hơn nhưng nhiều công ty thiếu các số liệu hiệu suất cơ bản hoặc các cách để đo lường hiệu suất tốt hơn có nghĩa là gì. Hiệu suất có liên quan đến trải nghiệm người dùng cuối không? Hiệu suất có dựa trên việc mở rộng quy mô và thu nhỏ khối lượng công việc để giảm mức tiêu thụ không? Hiệu suất có được đo bằng thời gian giảm bớt để triển khai hoặc nâng cấp không? Sau khi bạn thiết lập cách bạn sẽ đo lường hiệu suất, bạn có thể gắn nó với các ứng dụng, khách hàng và doanh nghiệp của mình.

Điều này sẽ cho phép bạn đánh giá xem các ứng dụng có hoạt động kém trong và sau khi di chuyển hay không. Nó cũng giúp quản lý nhận thức trong quá trình thay đổi đáng kể và giúp định lượng mức độ thành công. Bạn sẽ cần phải so sánh các nền tảng trước và sau khi di chuyển của mình với các khối lượng công việc tương tự. Những gì bạn đo lường tùy thuộc vào yêu cầu kinh doanh, nhưng một số phép đo chung là:

• Thời gian chạy thành phần
• Thời gian phản hồi ứng dụng
• Thời gian thực thi tổng thể của ứng dụng
• Thử nghiệm các ứng dụng để xác nhận khả năng truy cập dịch vụ và kết nối thành phần
• Chỉ số API (tải trang, sử dụng bộ nhớ, CPU, hiệu suất máy chủ)
• Tải đầu ra nhật ký
• Tỷ lệ tải báo cáo theo thời gian
• Tự động hóa (và coi tự động hóa như một công dân hạng nhất vì nó sẽ cải thiện hiệu suất tổng thể)
• Thay đổi chi phí hoạt động do quá trình di chuyển và tự động hóa nhiệm vụ
• Thử nghiệm với các loại ứng dụng mô hình hóa môi trường của bạn.

Trang tổng quan tốt: Bạn không thể di chuyển những gì bạn không thể tìm thấy

Hầu hết các tổ chức biết những gì họ đang hỗ trợ hiện tại nhưng cần xác định những gì họ muốn hỗ trợ sau khi di chuyển. Việc biết số lượng phiên bản ứng dụng rất dễ dàng vì nhà cung cấp của bạn có thể sẽ lập hóa đơn cho bạn dựa trên số liệu này. Tuy nhiên, bạn cũng sẽ cần biết số lượng ứng dụng, nhóm hỗ trợ ứng dụng nào, những ứng dụng có sự phụ thuộc lẫn nhau và loại dịch vụ mà mỗi ứng dụng đang sử dụng. Việc xác định các biến này sẽ giúp xác định cách bạn có thể vừa di chuyển vừa hỗ trợ môi trường mới.

Trong khi xác định chủ sở hữu của từng ứng dụng, điều cần thiết là phải xác định ứng dụng nào có tập lệnh kiểm tra tự động để xác nhận ứng dụng đang hoạt động. Lý tưởng nhất là mọi ứng dụng đều có các tập lệnh kiểm tra tự động, nhưng ít nhất, bạn cần có một bản đồ của các chủ sở hữu ứng dụng. Ngoài ra, bạn sẽ cần phải tìm kiếm các ứng dụng không sử dụng và chưa được sử dụng. Điều cuối cùng bạn muốn làm là di chuyển một ứng dụng không hoạt động (chúng tôi đã thấy điều này xảy ra) khi ứng dụng cần xóa hoặc sửa trước khi di chuyển. Một số lần đáng ngạc nhiên, bạn sẽ thấy rằng bản đồ tổng thể của các chủ sở hữu ứng dụng không tồn tại, gây ra các vấn đề trong và sau khi di chuyển.

Vì vậy, trọng tâm là “hàng tồn kho, hàng tồn kho, hàng tồn kho” vì nhiều công ty không có một vị trí trung tâm để liệt kê những người sở hữu mỗi ứng dụng, mỗi ứng dụng có hoặc làm gì và tác động kinh doanh của ứng dụng đó ra sao. Khả năng nhanh chóng truy vấn và tìm kiếm thông tin có liên quan là rất quan trọng đối với hoạt động, hiệu quả và việc ra quyết định kinh doanh.

Bắt đầu từ đâu? Trước tiên, hãy trả lời các câu hỏi rộng hơn:

• Bạn đang chạy ở những vùng nào và tại sao?
• Những ứng dụng nào đang chạy ở mỗi khu vực?
• Mỗi ứng dụng đang sử dụng những dịch vụ gì ở mỗi khu vực?
• Phiên bản Linux nào đang được sử dụng?
• Ứng dụng nào giao tiếp với các ứng dụng khác trong một khu vực?
• Ứng dụng nào hướng tới khách hàng so với ứng dụng nội bộ?

Việc thu thập các điểm dữ liệu ban đầu này sẽ không trả lời tất cả các ẩn số, nhưng chúng sẽ bắt đầu cung cấp những hiểu biết sâu sắc mà bạn cần.

Kiểm tra những gì bạn có thể: và chấp nhận những điều không thể biết

Cho dù bạn kiểm tra hoặc ghi lại từng chi tiết tốt đến đâu, sẽ có những biến số chưa biết ảnh hưởng đến thời gian ngừng hoạt động, khách hàng, đồng nghiệp, chi phí và dòng thời gian. Những ẩn số này chỉ có thể được tìm thấy khi đội ngũ kỹ thuật nhúng tay vào quá trình di chuyển. Đây là cách bạn có thể hỗ trợ họ:

• Thêm dòng thời gian cho những ẩn số
• Có sẵn nhiều tài nguyên hơn để trợ giúp khi một mặt hàng không xác định gây ra sự cố
• Linh hoạt với các chính sách của công ty, các cuộc họp nội bộ và triển khai tính năng mới
• Có sẵn kế hoạch dự phòng chẳng hạn như khôi phục nếu thử nghiệm không thành công
• Tập trung vào những chiến thắng nhỏ trước để có động lực trong khi lên kế hoạch cho những chiến thắng lớn. Hãy nhớ rằng, các chiến thắng nhanh hữu hình có thể giúp ích cho tinh thần miễn là nó không gây ra nhiều chi phí hoạt động hơn.

Phương pháp được ưu tiên là thực hiện một cuộc đánh giá hoàn chỉnh và ghi lại các cơ cấu tổ chức và các mối quan hệ và sử dụng nó để tham khảo trong suốt quá trình làm việc. Khi dự án bắt đầu, tài liệu này sẽ trở thành bản đồ của bạn và giúp tránh bỏ ưu tiên hoặc tạm dừng các mục. Bạn có thể nhận thấy rằng việc chuyển lên quản lý cấp trên có thể được yêu cầu để ưu tiên các hành động mà bạn cần thực hiện. Tuy nhiên, ưu tiên nên là hiểu cách thức hoạt động của các nhóm riêng lẻ và thiết lập giao tiếp tốt với họ hơn là tìm hiểu kỹ càng.

An ninh: Đưa Nhóm SecOps đi ăn trưa

Chúng tôi không ngụ ý điều này trong kiểu "Đưa họ đi dạo" của Tony Soprano; chúng tôi thực sự muốn đưa đội an ninh ra ngoài ăn trưa để thiết lập mối quan hệ trực tiếp. Nhóm bảo mật rất quan trọng đối với quá trình di chuyển để hạn chế, nới lỏng hoặc cung cấp giải pháp thay thế cho các trình chặn phát sinh. Bạn cũng cần họ xem xét nhanh chóng bất kỳ phần mềm mới nào cần thiết để giúp quá trình di chuyển của bạn thành công. Một nhóm bảo mật bị bỏ quên sẽ là một kẻ chặn đứng. Hãy đối mặt với nó với một bộ phim tương tự khủng khiếp khác bảo mật không bao giờ muốn là Hiệp sĩ đen từ Monty Python hét lên, "Không ai sẽ vượt qua!" nhưng họ thực sự muốn đóng vai trò quan trọng là giữ mọi thứ an toàn. Cuối cùng, bảo mật muốn cho phép tất cả mọi người trong tổ chức miễn là có các nguyên tắc phù hợp. Nếu bạn cho họ tham gia sớm, bạn sẽ tránh được đau đầu khi an ninh bị kéo đến vào phút cuối.

Chống lại Scope Creep: Đó là một ý tưởng thực sự tuyệt vời… cho năm tới

Phạm vi creep cần được quản lý cẩn thận. Tất cả các tổ chức đều muốn giải quyết các vấn đề của họ đồng thời, nhưng bạn nên tập trung vào việc giải quyết một vấn đề rất cụ thể. Lấy ví dụ về việc chuyển từ Pivotal Cloud sang Cloud Foundry nguồn mở, điểm mạnh chính của Cloud Foundry là nhiều tính năng có thể được thêm vào và tiềm năng tùy chỉnh. Ví dụ: cải thiện tư thế phục hồi sau thảm họa và sao lưu có thể hấp dẫn, nhưng việc tạo thêm phạm vi sẽ tạo thêm điểm đau.

Scope creep cũng tạo ra một vấn đề trong đó một cái gì đó có thể bị vỡ và bạn không thể chắc chắn liệu sự cố đó là do mục tiêu dự án tổng thể của bạn hay do phạm vi bổ sung.

Phản chiếu: Phù hợp với thế giới mà bạn muốn bỏ lại phía sau

Khi bạn đã thiết lập các tham số cho dự án của mình và các kết quả mong muốn, bạn phải đảm bảo rằng bạn đã sao chép tất cả các môi trường sẽ được di chuyển. Điều này bao gồm môi trường hoạt động của bạn hoặc “sân chơi”, nơi bạn sẽ chứng minh mọi thứ trước đây, chuyển sang phi sản xuất và cuối cùng là sản xuất.

Khi xây dựng môi trường sân chơi, bạn sẽ muốn đảm bảo rằng công nghệ hiện tại, trong ví dụ Pivotal của chúng tôi, giống với môi trường phi sản xuất của bạn. Điều này sẽ cho phép bạn tự tin hơn rằng bạn sẽ gặp ít vấn đề hơn.

Các vấn đề quản lý: Kết bạn ở những nơi cao

Bạn sẽ cần sự hỗ trợ từ ban quản lý, vì vậy không nên vẽ một bức tranh hoàn toàn màu hồng. Những cuộc di cư có một con đường dài phía trước họ. Di chuyển nền tảng là một chuyện, nhưng bạn cũng phải đối phó với tất cả các dịch vụ. Ban quản lý cần biết cách tiếp cận của bạn đối với việc di chuyển và kế hoạch của bạn để giảm thiểu rủi ro kinh doanh. Ban quản lý sẽ lo lắng vì việc di cư có thể ảnh hưởng đến lợi nhuận, vì vậy bạn cần thảo luận về tất cả các biện pháp của mình để tránh điều đó.

Không thành công: Làm cho nó thành công

Thất bại là tốt, thất bại cũng lớn, và thất bại nên được mong đợi miễn là bạn thực hiện các bài học kinh nghiệm trong lần tiếp theo. Bạn không thể giải thích cho tất cả mọi thứ, và những thất bại có thể nhận ra sẽ xảy ra khi những ẩn số trở thành vật cản. Việc cho quản lý biết sẽ có thất bại hy vọng sẽ tránh được những ý nghĩa tiêu cực và cải thiện tinh thần tổng thể. Trên thực tế, bạn cần ăn mừng những gì học được từ thất bại bởi vì bạn đang tiến bộ. Để bán được mà thất bại có thể chấp nhận được, bạn cần có một kế hoạch dự phòng rõ ràng. Có điều này như là một phần của kế hoạch ngày di chuyển của bạn với các điểm quyết định đi / không đi để quay trở lại.

Phí cấp phép và rủi ro là những động lực chính cho việc di chuyển sang Tổ chức đám mây nguồn mở hoặc Kubernetes. Đối với các tổ chức lớn đang chạy hàng nghìn ứng dụng, cổ phần là nhiệm vụ quan trọng. Với nhu cầu ngày càng tăng về quy mô và sự thiếu hụt nhà phát triển, việc di chuyển có vẻ rủi ro. Mối quan tâm chính là tránh ảnh hưởng đến các nhóm ứng dụng và tránh thời gian chết. Tin tốt là Stark & Wayne đã thực hiện nhiều chuyển đổi quy mô doanh nghiệp thành công tuân theo tác động của nhà phát triển ở mức tối thiểu và thời gian ngừng hoạt động chỉ giới hạn ở việc thay đổi cửa sổ điều khiển.

Bằng cách tính toán những sai lầm phổ biến mà chúng tôi đã gặp phải này, dự án tiếp theo của bạn ít có khả năng trở thành một phần của 70% mà Boston Consulting Group đề xuất là không đạt được những gì họ mong đợi.

Cũng được xuất bản ở đây .