- Chia sẻ các trường hợp áp dụng hiệu quả các khái niệm DevOps, staff engineering và platform engineering trong môi trường startup
- Diễn giả Chad McElligott là Senior Staff Engineer tại Smartrr, một công ty cung cấp dịch vụ đăng ký và loyalty dựa trên Shopify
- Đề xuất phương pháp luận kỹ thuật phù hợp với văn hóa và yêu cầu đặc thù của startup
[Khái niệm cốt lõi]
DevOps
- Mỗi người có một định nghĩa khác nhau về DevOps; với người này đó là một chức danh, với người khác đó là một cách làm việc
- Khái niệm "DevOps as No Ops" khiến kỹ sư phần mềm tự xử lý toàn bộ công việc liên quan đến Ops
- DevOps là tư duy hợp tác, tự động hóa các công việc lặp lại và thủ công ( toil ), và tận dụng công cụ hiện đại để nhanh chóng mang lại giá trị cho khách hàng
- Cốt lõi không chỉ là các yếu tố kỹ thuật như sử dụng cloud, hạ tầng dưới dạng mã, xây dựng pipeline CI/CD, mà còn là phá bỏ rào cản giao tiếp và hợp tác để đạt kết quả tốt hơn
Platform Engineering
- Platform Engineering là cách tiếp cận kỹ thuật nhằm giảm tải nhận thức cho nhà phát triển
- Mục tiêu là đồng thời tăng tốc độ phát triển sản phẩm và độ ổn định hệ thống, bằng cách cung cấp các thành phần nền tảng hỗ trợ hoạt động của lập trình viên
- Ngày càng có nhiều trường hợp các doanh nghiệp lớn xây dựng đội platform engineering để nâng cao hiệu quả và cải thiện trải nghiệm lập trình viên
- Khái niệm này được phổ biến rộng rãi qua cuốn Team Topologies của Manuel Pais và Matthew Skelton, và có thể thấy nhiều ví dụ về tăng cường năng lực kỹ thuật trên nhiều kênh khác nhau
Staff Engineering
- Staff Engineering không phải là một mindset hay kỹ năng cụ thể, mà là một vai trò mà kỹ sư phần mềm đảm nhiệm trong tổ chức
- Đây là giai đoạn nghề nghiệp sau Senior Software Engineer, và cũng có thể được mô tả là servant leadership trong kỹ nghệ phần mềm
- Kỹ sư Staff+ không chỉ mở rộng trách nhiệm cá nhân mà còn mở rộng trách nhiệm với toàn tổ chức, hợp tác với quản lý hoặc VP để cung cấp góc nhìn và khả năng thực thi thực tế
- Trong cuốn Staff Engineer, Will Larson chia vai trò Staff thành bốn archetype (Architect, Right Hand, Tech Lead, Fixer)
[Văn hóa startup]
- Startup dựa trên vốn đầu tư mạo hiểm thường chi nhiều hơn doanh thu để theo đuổi tăng trưởng
- Họ sử dụng nguồn vốn huy động được như "runway" để tăng trưởng nhanh, và phải đạt được tăng trưởng cùng khả năng sinh lời trước khi runway cạn kiệt
- Môi trường này tạo ra hai đặc tính văn hóa cốt lõi
- Không có thời gian để lãng phí
- Trong startup, lãng phí thời gian đặc biệt nguy hiểm
- Đội ngũ phát triển phải tập trung vào các mục tiêu chiến lược của tổ chức và thực thi trong giới hạn runway
- Mỗi thành viên cần thường xuyên kiểm tra xem hoạt động của mình có phù hợp với mục tiêu hay không, và điều chỉnh lại nếu cần
- Ngay cả khi một thử nghiệm thất bại, nếu có cấu trúc để học hỏi và rút ra được bài học mong muốn thì đó không phải là lãng phí
- Ai cũng đảm nhiệm nhiều vai trò
- Trong tổ chức nhỏ, có rất nhiều việc phải làm nhưng lại thiếu người để làm
- Ví dụ, một lập trình viên frontend có thể kiêm luôn product designer, technical writer, product manager, QA và phụ trách tích hợp bên thứ ba
- Khi xuất hiện ý tưởng mới để cải thiện trải nghiệm khách hàng, người đề xuất ý tưởng đó cũng có thể phải trực tiếp chịu trách nhiệm tạo prototype hoặc hiện thực hóa nó
- Những đặc tính văn hóa này quyết định năng lực cần có của nhóm phát triển sản phẩm, đặc biệt là các lãnh đạo kỹ thuật phần mềm
- Đồng thời, chúng cũng gợi ý cách DevOps, Platform Engineering và Staff Engineering cần thích nghi với môi trường startup
[Áp dụng các nguyên tắc kỹ thuật (Tenet) của tôi vào văn hóa startup]
DevOps trong startup
- Trong startup, việc thay đổi quy trình khá dễ.
- Vì số lượng người ít nên không có nhiều rào cản khi áp dụng cách làm mới
- Điều chỉnh quy trình theo công cụ sẽ mang lại kết quả tối ưu
- Nếu giữ quy trình cứng nhắc, sẽ phải tùy biến công cụ hoặc phát triển thêm phần mềm, dẫn đến lãng phí thời gian
- Cần tránh tối đa công cụ tự xây
- Nên tận dụng hạ tầng serverless, công cụ SaaS, thư viện mã nguồn mở, v.v.
- Hãy đi theo dòng chảy chung của công nghệ, và không nên tùy biến công nghệ nếu nó không mang lại lợi thế cạnh tranh khác biệt
- Tham khảo: Utility vs Strategic Dichotomy của Martin Fowler
- Nên chọn "công nghệ nhàm chán"
- Không nên đặt cược rủi ro lớn vào những giải pháp mà đội ngũ chưa quen hoặc có cộng đồng hỗ trợ yếu
- Hãy chọn công nghệ mà khi phát sinh vấn đề, có thể dễ dàng tìm được cách giải quyết trên mạng
- Có thể xem bài nói giải thích chi tiết ý tưởng này tại boringtechnology.club của Dan McKinley
Platform Engineering trong startup
- Nội dung được nhắc đến trong Engineering Unblocked podcast của Rebecca Murphey:
- "Trải nghiệm lập trình viên của một công ty là một sản phẩm, dù nó có được thiết kế như vậy hay không"
- Ngay cả ở quy mô startup, vẫn cần monitoring, deployment, theo dõi lỗi, kiểm tra log và chuyển đổi feature flag
- Câu hỏi quan trọng là: "Những công việc này có gây đau đớn không?"
- Platform Engineering là một vai trò bán thời gian trong startup
- Ban đầu có thể cần một môi trường kiểm thử tích hợp, nhưng về sau nó có thể bị đẩy xuống ưu tiên thấp hơn
- Vai trò platform engineering sẽ chỉ được thực hiện khi cần thiết
- Không có dư địa để theo đuổi các dự án platform dài hạn
- Thay vào đó, cần hiện thực hóa các yếu tố có giá trị thông qua những phần việc nhỏ
- Cần chia sẻ bức tranh lớn và tầm nhìn với đội ngũ, đồng thời giúp họ hiểu các mảnh nhỏ kết nối với nhau như thế nào
- Công việc platform ở startup là quá trình khai phá năng suất và cách tiếp cận mới
- Phần lớn không phải là chuyển từ phần mềm cũ sang công cụ hiện đại, mà là xây dựng mới những thứ vốn chưa tồn tại
- Điều quan trọng không phải là có thể làm gì, mà là phải quyết định nên làm gì
- Cần tập trung vào những việc giải quyết vấn đề hiện tại của tổ chức hoặc vấn đề trong tương lai gần
- Cần xác định việc cần làm thông qua kinh nghiệm thực tế, trao đổi với kỹ sư, phản hồi từ retrospective, phân tích chỉ số SDLC (vòng đời phát triển phần mềm), v.v.
- Đôi khi, tốt hơn là hoãn công việc platform lại và tập trung vào những nhu cầu khác
- Cốt lõi là tiếp cận một cách linh hoạt
Staff Engineering trong startup
- Vai trò Staff Engineer rất phù hợp với môi trường startup
- Chuyên môn kỹ thuật sâu, xu hướng tìm kiếm ảnh hưởng rộng, và thái độ sẵn sàng xắn tay vào bất cứ nơi nào cần để giải quyết vấn đề kinh doanh đều rất hợp với startup
- Trong các tổ chức lớn, có câu nói rằng "biết nơi kỹ thuật nợ bị chôn giấu"
- Staff Engineer sẽ tìm người nắm giữ kiến thức đó, hệ thống hóa lại và đưa ra các quyết định để tiến về phía trước
- Ở startup, technical debt và các vấn đề hiện ra rất rõ ràng
- Staff Engineer có thể tạo ảnh hưởng lớn bằng cách sắp xếp lại sự hỗn loạn này và xây dựng các giải pháp có ích lâu dài cho tổ chức
- Trong startup, Staff Engineer không thể chỉ ở yên trong một archetype
- Vì quy mô tổ chức nhỏ nên phải thực hiện nhiều hoạt động khác nhau, bao gồm cả trực tiếp triển khai
- Không chỉ thiết kế kiến trúc, dẫn dắt dự án và xử lý công việc chiến thuật, mà còn phải tự mình đưa ra ý tưởng cải tiến và thực thi chúng
- Sự linh hoạt và tinh thần chủ động nhận trách nhiệm là phẩm chất thiết yếu của kỹ sư Staff+ trong startup
- Một trong những vai trò quan trọng của kỹ sư Staff+ là mentoring và sponsorship
- Đây là sự hỗ trợ và định hướng đặc biệt quan trọng với nhân sự junior trong startup
- Staff Engineer thúc đẩy sự phát triển của đội ngũ và tăng cường năng lực tổ chức thông qua sự hỗ trợ này
[Áp dụng modern staff engineering trong startup]
Câu chuyện 1 trong 2 - "Improving DevEx by Removing a Merge Freeze"
Vấn đề
- Quy trình QA hiện tại:
- Áp dụng "merge freeze" trong 2-3 ngày trước khi phát hành và đội QA thực hiện kiểm thử hồi quy thủ công
- Các lỗi được phát hiện sẽ được sửa ngay và hợp nhất vào nhánh main
- Nhà phát triển tạo bản vá mới nhưng phải hoãn merge request đến sau khi phát hành
- Nhược điểm:
- Kiểm thử hồi quy thủ công chậm và khó dự đoán
- Việc trì hoãn hợp nhất làm tăng tần suất xảy ra merge conflict
- Năng suất và khả năng cộng tác của nhà phát triển bị giảm sút
Giải pháp
- Tích hợp mã hạ tầng vào Monorepo
- Tích hợp dự án Terraform vào cùng repository với mã ứng dụng
- Kết nối với các công cụ linting và quản lý phụ thuộc tự động để giúp nhà phát triển xử lý hạ tầng dễ hơn
- Quản lý mọi môi trường bằng Terraform
- Không chỉ môi trường mới mà cả staging và production hiện có cũng được quản lý bằng Terraform
- Duy trì tính nhất quán giữa các môi trường bằng cách áp dụng các biến khác nhau trên cùng một định nghĩa hạ tầng
- Đơn giản hóa quy trình CI/CD
- Template GitLab Auto DevOps hiện có đã trở nên phức tạp do bị tùy biến quá nhiều
- Loại bỏ Auto DevOps và định nghĩa rõ ràng file
.gitlab-ci.yml mới
- Chuyển phần lớn lệnh sang Makefile để cũng có thể chạy thủ công
- Cải thiện quản lý secrets
- Chuyển secrets của ứng dụng sang Google Cloud Secrets Manager để giảm độ phụ thuộc vào GitLab
- Chỉnh sửa script triển khai để tự động cập nhật Kubernetes ConfigMap
- Các hạng mục nằm ngoài phạm vi
- Ứng dụng đang chạy trên Kubernetes với kiến trúc monolith
- Việc thay đổi điều này có thể gây chậm trễ và rủi ro nên được giữ nguyên
- Không xây dựng pipeline tự động hóa Terraform
- Do thay đổi hạ tầng tương đối ít nên vẫn giữ quy trình thủ công
- Cách tiếp cận truy cập secret theo kiểu native của Kubernetes cũng được tạm hoãn
Kết quả và thành quả
- Đã triển khai môi trường kiểm thử mới để đội QA có thể tự thực hiện kiểm thử hồi quy
- Việc loại bỏ merge freeze cho phép nhà phát triển tự do hợp nhất thay đổi vào nhánh main
- Quy trình phát hành được tinh gọn và tốc độ của toàn đội được cải thiện
Các nguyên tắc được áp dụng
- Nguyên tắc Staff Engineering
- Dẫn dắt dự án trong khi cộng tác với nhiều đội khác nhau
- Đảm nhiệm vai trò "Tech Lead" và đưa dự án đến hoàn thành
- Nâng cao mức độ thấu hiểu và khả năng tiếp cận của cả đội thông qua cải thiện CI/CD và hạ tầng
- Nguyên tắc Platform Engineering
- Mở rộng dự án DevOps thành một dự án nền tảng
- Quản lý toàn bộ hạ tầng dưới dạng mã để bảo đảm tính nhất quán giữa các môi trường
- Điều chỉnh phạm vi dự án thông qua các đánh đổi thực tế
- Nguyên tắc DevOps
- Quản lý hạ tầng dưới dạng mã để vận hành hạ tầng đám mây một cách nhất quán
- Cải thiện quy trình phát hành và tăng tốc độ phát triển bằng công cụ mới
- Áp dụng định dạng tài liệu RFC(Request For Comment) để tăng tính bao trùm trong quá trình ra quyết định
Kết luận
- Đội QA đã có thể chạy kiểm thử tự động trong một môi trường ổn định hơn
- Nhà phát triển có thể phát triển liên tục mà không cần merge freeze, đồng thời khả năng cộng tác cũng được tăng cường
- Năng suất của tổ chức được cải thiện nhờ công cụ và quy trình tốt hơn
- Trong tương lai, tác giả muốn tiếp tục triển khai thêm các hạng mục như xây dựng môi trường preview hoặc tự động hóa kiểm thử hồi quy
Câu chuyện 2 trong 2 - "Iterating Towards a Productive Engineering Process"
Vấn đề
- Quy trình hiện tại:
- Mọi thành viên trong đội làm việc trên một board duy nhất và chia sẻ tiến độ hằng ngày
- Nhiều người không tập trung khi chưa đến lượt mình và rơi vào trạng thái "check-out"
- Trách nhiệm phát triển tính năng bị phân tán, khiến product manager thường phải chịu trách nhiệm cuối cùng
- Thiếu sự hiểu biết rõ ràng về kiến trúc kỹ thuật
- Mục tiêu:
- Thực hiện nhiều thử nghiệm khác nhau để xây dựng quy trình cộng tác và phát triển phần mềm tốt hơn
- Thử nghiệm 1: Đội tính năng ngắn hạn(Short-lived Feature Teams)
- Mục đích: trao cho kỹ sư tinh thần trách nhiệm đối với toàn bộ vòng đời phát triển tính năng
- Cách làm:
- Chỉ định leader cho từng tính năng và tổ chức đội gồm backend, frontend, QA...
- Kết quả:
- Tinh thần trách nhiệm của thành viên được cải thiện, nhưng không phải ai cũng phù hợp hoặc mong muốn vai trò leader
- Sau đó chuyển sang "mô hình đội cố định" để lập các "Squads", mỗi đội tự lên kế hoạch và tự retrospective
- Thử nghiệm 2: Epic Kickoff Documents
- Mục đích: làm rõ yêu cầu và giúp đội đạt đồng thuận về phạm vi dự án cũng như cách tiếp cận
- Cách làm:
- Kết quả:
- Giao tiếp trong đội được cải thiện và việc cộng tác tốt hơn ngay từ đầu dự án
- Các thành viên đánh giá đây là khoảng thời gian có giá trị
- Thử nghiệm 3: Group Code Review
- Mục đích: rút ngắn thời gian code review, thúc đẩy thảo luận về mã và chia sẻ kỹ thuật giữa các kỹ sư
- Cách làm:
- Tổ chức phiên code review kéo dài 1 giờ trên Slack Huddle hai lần mỗi tuần
- Nhà phát triển chia sẻ màn hình để giải thích PR và người tham gia đưa ra phản hồi
- Kết quả:
- Thời gian cho code review giảm mạnh và duy trì trạng thái Inbox 0
- Thông qua thảo luận về mã, hình thành văn hóa để các nhà phát triển học hỏi lẫn nhau và tôn trọng nhau
- Ngoài code review, lợi ích của pair programming cũng được giới thiệu đến đội
Các nguyên tắc được áp dụng
- Nguyên tắc Staff Engineering
- Dẫn dắt cải tiến quy trình khi không có engineering manager
- Đưa văn hóa cải tiến liên tục vào đội và tăng cường cộng tác tự chủ thông qua quy trình Agile
- Hỗ trợ đội phá vỡ quy trình trì trệ để tìm ra cách làm tốt hơn
- Nguyên tắc Platform Engineering
- Xem quy trình cũng là một phần của nền tảng, chứ không chỉ công cụ
- Quy trình kém hiệu quả cản trở năng suất của đội, vì vậy việc cải thiện nó là rất quan trọng
- Những thay đổi quy trình nhằm loại bỏ lãng phí có thể tạo tác động lớn ngang với cải thiện công cụ
- Nguyên tắc DevOps
- Nguyên tắc CALMS: cộng tác(Collaboration), tự động hóa(Automation), tinh gọn(Lean), đo lường(Measurement), chia sẻ(Sharing)
- Thông qua quy trình tinh gọn(Lean), loại bỏ lãng phí và chuyển giao giá trị nhanh hơn
- Hướng dẫn đội cải tiến liên tục thông qua quy trình Agile
Kết luận
- Việc cải thiện quy trình của đội theo hướng thử nghiệm đã giúp năng suất và cộng tác tăng lên đáng kể
- Những cải tiến chi phí thấp, hiệu quả cao đã nâng cao trải nghiệm phát triển của toàn đội
- Tác giả đặc biệt khuyến nghị hãy xem xét quy trình của chính mình một cách phản biện và tìm ra dư địa để cải thiện
[Kết]
- Khi làm việc trong môi trường startup, có thể phát huy cả chuyên môn lẫn đam mê trong quá trình giải quyết nhiều vấn đề khác nhau và hiện thực hóa giải pháp
- Vì có những ràng buộc về thời gian, đây là cơ hội tốt để rèn luyện cách tiếp cận thực dụng, đồng thời có thể tạo ra ảnh hưởng lớn ở giai đoạn đầu của công ty
- Có thể áp dụng các phương pháp kỹ nghệ phần mềm hiện đại để đặt nền móng cho thành công của công ty
-
Staff Engineering và startup
- Staff Engineer đòi hỏi kinh nghiệm có cả bề rộng lẫn chiều sâu
- Startup mang đến cơ hội để các kỹ sư Staff+ mở rộng kiến thức kỹ thuật và khám phá những lĩnh vực mới
- Ví dụ: kỹ sư backend có thể học các công nghệ như React hoặc BigQuery
-
Platform Engineering và startup
- Platform Engineering ở startup thay đổi tùy theo quy mô
- Có thể xác định pain point của nhà phát triển thông qua giao tiếp 1:1 và cải thiện trải nghiệm nhà phát triển (DevEx) bằng các dự án nhỏ
- Cần xây dựng vòng phản hồi nhanh để cải thiện quy trình phát triển, đồng thời giúp các nhà phát triển có thể tự giải quyết vấn đề trong tương lai
- Điều quan trọng là đáp ứng các yếu tố cơ bản của vòng đời phát triển phần mềm (SDLC) bằng các công cụ và kỹ thuật tiêu chuẩn ngành
- Ở startup, Platform Engineering không phải là công việc chuyên trách mà là một cách tiếp cận kỹ thuật được áp dụng khi cần
- Hãy ghi nhớ rằng "trải nghiệm nhà phát triển của doanh nghiệp là một sản phẩm" và dành thời gian để thiết kế nó
-
DevOps và startup
- DevOps cũng đóng vai trò rất quan trọng trong startup
- Cốt lõi là mang lại giá trị cho khách hàng nhanh hơn thông qua văn hóa, quy trình, công cụ, đồng thời tạo ra môi trường làm việc tốt hơn
- Việc nâng cao hiệu quả của công ty và xây dựng văn hóa cộng tác thông qua DevOps là một quá trình rất đáng giá
- Trong startup, những kỹ sư có đam mê với DevOps có thể đóng góp rất lớn bằng kỹ năng và kinh nghiệm của mình
- Môi trường startup đầy ắp những thử thách mới và cơ hội học hỏi; thông qua đó, kỹ sư có thể trưởng thành hơn và tạo ra những thành quả ý nghĩa
3 bình luận
Điếu văn cho DevOps
Kỹ sư nền tảng kiếm nhiều tiền hơn kỹ sư DevOps
Staff Engineer là gì?
Có vẻ như bài này đã định nghĩa khá rõ những vai trò kỹ thuật sẽ cần trong các startup về sau. Cũng có vẻ như đã hệ thống hóa tốt những công việc kỹ thuật trước đây vốn được làm mà không có sự phân chia rõ ràng. Bản thân mỗi người cũng có thể biết cụ thể mình đang phụ trách kiểu công việc kỹ thuật nào và sau này muốn làm tốt điều gì. Nhờ vậy, ngay cả startup cũng có thể xây dựng được một hệ thống kỹ thuật bài bản và tuyển đúng những kỹ sư cần thiết.