Giám sát Engineering PracticesEngineering Practices Oversight

Thuộc bộ kiến thức Engineering Manager Roadmap.

Tổng quan

Một engineering manager (EM) thường không viết code production hàng ngày, và ngay cả khi có viết, họ cũng không thể tự mình review mọi pull request, chạy mọi test suite, hay theo dõi mọi lần deploy. Điều giúp một manager tin tưởng rằng một team tám, hai mươi, hay tám mươi engineer đang ship an toàn mà không cần loại giám sát cá nhân liên tục đó chính là sự tồn tại của các engineering practices tốt: CI/CD, code review, testing, và security work đủ mạnh để đóng vai trò guardrail. Các practice này thực hiện việc thực thi hàng ngày; công việc của manager là quyết định guardrail trông như thế nào, nhận ra khi nào chúng bắt đầu xuống cấp, và đưa ra các quyết định đầu tư giữ cho chúng khỏe mạnh.

Đây là một sự chuyển đổi tư thế tinh tế nhưng quan trọng. Một manager mới cố gắng bù đắp cho quy mô tổ chức bằng cách tự mình review nhiều code hơn, hoặc trở thành chốt chặn cuối cùng trước mỗi lần deploy, không phải đang scale — họ đang trở thành chính cái bottleneck mà lẽ ra họ phải loại bỏ. Giải pháp thay thế là coi practices như hạ tầng: thứ bạn thiết kế, cấp ngân sách, đo lường, và giao việc vận hành hàng ngày cho tech lead cùng senior engineer, giống như bạn giao việc vận hành một service cho một on-call rotation thay vì chính bạn ngồi nhìn dashboard cả ngày.

Note này cố tình tập trung vào tầng giám sát (oversight layer) — những gì EM quyết định, thực thi, và đo lường — chứ không phải cơ chế kỹ thuật của việc pipeline được xây dựng ra sao, một công cụ diff hoạt động thế nào, hay một test framework được cấu hình ra sao. Những cơ chế đó nằm ở nơi khác trong bộ kiến thức này và được liên kết xuyên suốt: CI/CD, Version Control & Collaboration, Testing, và DevSecOps knowledge base. Đọc note này cùng với Agile Process & Delivery, nói về cách công việc luân chuyển qua team, và Technical Decision-Making & Architecture, nói về các lựa chọn thiết kế ở tầng cao hơn quyết định việc duy trì các practice này khó hay dễ ngay từ đầu.

Kiến thức nền tảng

Mô hình giám sát: guardrail, không phải gate

Mô hình tư duy cốt lõi là: một manager đóng vai trò gate (chốt chặn) tự mình đứng giữa mọi công việc và việc release nó, và tốc độ của team bị giới hạn bởi băng thông của manager. Một manager xây dựng guardrail (hàng rào bảo vệ) — CI phải xanh, code review phải xảy ra, security scanning phải pass — cho phép team di chuyển theo nhịp riêng của mình bên trong các ranh giới manager đã thiết kế, mà không cần có mặt trong phòng. Guardrail scale được; gate thì không.

Điều này có nghĩa là sự tham gia thực tế hàng ngày của EM vào engineering practices trông không giống “review code” mà giống hơn với:

Câu hỏi EM đặt ra	Nó tiết lộ điều gì
Pipeline CI của chúng ta nhanh và đáng tin, hay là thứ mọi người tìm cách né tránh?	Guardrail có thực sự chịu lực hay không
Code review có diễn ra trong một SLA hợp lý, hay đang xếp hàng nhiều ngày?	Review có phải là một chốt chất lượng thật sự hay chỉ là hình thức gây nghẽn
Team có biết, với tư cách tập thể, test coverage của mình mang lại gì — và ở đâu thì không?	Đầu tư testing có khớp với rủi ro thực tế hay không
Security là việc một người làm ở cuối, hay việc mọi người làm xuyên suốt?	”Shift-left” là thật hay chỉ là khẩu hiệu
Các chỉ số DORA của chúng ta nói gì về hệ thống, không phải về một engineer cụ thể?	Các practice có đang tạo ra kết quả mà chúng được thiết kế để tạo ra hay không

Không câu hỏi nào trong số này đòi hỏi EM phải mở một diff hay đọc một stack trace. Chúng đòi hỏi EM nhìn vào xu hướng, trò chuyện với tech lead, và quyết định nên dành thời gian engineering khan hiếm vào đâu.

Ai sở hữu cái gì: cơ chế vs. giám sát

Một bảng hữu ích cần ghi nhớ khi giao việc là ai sở hữu cơ chế hàng ngày của một practice so với điều manager chịu trách nhiệm cụ thể:

Practice	Sở hữu cơ chế hàng ngày	EM sở hữu
CI/CD pipeline	Tech lead / platform hoặc DevOps engineer cấu hình các stage, tooling, environment	Đặt tiêu chuẩn độ tin cậy/tốc độ, cấp ngân sách cho pipeline work so với feature, escalate khi hỏng dai dẳng
Code review	Senior engineer và reviewer thực hiện review thực tế	Đặt chuẩn mực SLA, ngăn bottleneck, dùng review để phát triển con người
Chiến lược testing	Engineer viết test; QA/test engineer có thể sở hữu framework	Quyết định mức đầu tư dựa trên rủi ro của team, bảo vệ thời gian cho nó
Security practices	Security champion / AppSec làm threat modeling, scanning, remediation	Đưa security vào định nghĩa “done”, bảo vệ ngân sách cho security work vô hình

Mô hình lặp lại: EM không vắng mặt khỏi các practice này, nhưng sự tham gia của họ nằm ở tầng chính sách, ngân sách, và escalation — không phải ở tầng thực thi.

CI/CD dưới góc nhìn quản lý

Cơ chế kỹ thuật sâu của pipeline — các stage, build-once-deploy-many, test pyramid bên trong CI, chiến lược deployment — được trình bày trong CI/CD. Từ ghế của EM, pipeline không phải là một artifact kỹ thuật để cấu hình; nó là thứ quyết định việc ship tốn kém đến mức nào cho cả team, mỗi ngày.

“Tốt” dưới góc nhìn quản lý có nghĩa là ba điều cùng lúc:

• Nhanh — một developer nhận được feedback về thay đổi của họ trong vài phút, không phải vài giờ. Nếu feedback loop chậm, engineer sẽ gộp thay đổi lại để khấu hao thời gian chờ, điều này phá vỡ việc delivery theo batch nhỏ và khiến việc chẩn đoán lỗi khó hơn khi nó xảy ra.
• Đáng tin cậy — build đỏ nghĩa là thực sự có gì đó sai, và build xanh có thể được tin tưởng. Một pipeline lỗi không nhất quán vì những lý do không liên quan đến thay đổi đang test sẽ dạy team chạy lại và bỏ qua, âm thầm phá hủy toàn bộ mục đích của việc kiểm chứng tự động.
• Được tin tưởng — team coi pipeline là con đường duy nhất tới production, không phải một thủ tục để né tránh bằng override thủ công “chỉ lần này thôi”.

Cái giá của việc làm sai điều này không hề trừu tượng. Một pipeline flaky hoặc chậm là một loại thuế lặp lại đánh vào tinh thần và tốc độ: engineer chuyển ngữ cảnh trong lúc chờ, mất trạng thái tập trung (flow), phát triển sự bất lực học được đối với CI (“nó luôn hỏng, cứ chạy lại”), và cuối cùng ngừng tin vào build xanh — lúc đó pipeline đã ngừng làm việc của nó dù về mặt kỹ thuật vẫn đang chạy. Đây là kiểu xuống cấp vô hình trong một sprint đơn lẻ nhưng tàn phá trong một quý, và đó chính xác là lý do nó cần sự chú ý quản lý có chủ đích thay vì giả định nó sẽ tự sửa.

Quyết định cụ thể mà EM sở hữu là khi nào rút engineer khỏi feature work để đầu tư vào sức khỏe pipeline. Không có con số phổ quát, nhưng các điểm kích hoạt hữu ích bao gồm: thời gian feedback build/test dần vượt quá mức team coi là “nhanh” (thường là 10–15 phút cho vòng feedback nhanh), tỷ lệ flaky test cao đến mức engineer thường xuyên chạy lại mà không điều tra, hoặc một pattern các sự cố được truy ra là do những lỗ hổng lẽ ra pipeline phải bắt được. Khi bất kỳ dấu hiệu nào trong số này xuất hiện lặp lại, việc coi sức khỏe pipeline là một hạng mục backlog hạng nhất — với story point thật và ưu tiên thật so với feature — là một quyết định quản lý, không phải một điều “hay thì làm” của engineering.

Code review dưới góc nhìn quản lý

Chi tiết kỹ thuật của pull request, branching, và review tooling nằm trong Version Control & Collaboration. Việc của EM là thiết lập môi trường chính sách mà review diễn ra bên trong.

Ba đòn bẩy quan trọng nhất:

• SLA cho review. Một pull request nằm không được review trong nhiều ngày không phải là một practice chất lượng — đó là độ trễ xếp hàng đội lốt chất lượng. Một chuẩn mực hợp lý là phản hồi đầu tiên (không nhất thiết là approve) trong vòng một ngày làm việc, nhanh hơn với các thay đổi nhỏ, ít rủi ro. Khi thời gian review thường xuyên vượt quá mức này, nó biểu hiện ở downstream thành các batch lớn hơn, rủi ro hơn (vì engineer chất thêm việc lên các branch chậm merge) và senior engineer bực bội vì cảm thấy review là một loại thuế không có phần thưởng.
• Kỹ lưỡng vs. tốc độ. Review tồn tại để bắt các vấn đề thiết kế và đúng đắn mà con người nên bắt được — không phải để bắt bẻ formatting mà linter lẽ ra đã bắt. Một EM nhận thấy review biến thành các cuộc tranh luận phong cách dài dòng nên đẩy team hướng tới tự động hóa những gì có thể tự động hóa (formatting, static analysis, các quy tắc lint đơn giản) để sự chú ý của con người dồn vào những gì máy móc không thể phán đoán: đây có phải thiết kế đúng, cái này có xử lý các edge case không, cái này có phù hợp với quy ước của codebase không.
• Ngăn ngừa bottleneck. Một team nơi chỉ tech lead mới có thể approve merge đã xây dựng một điểm lỗi đơn (single point of failure) ngụy trang thành một chốt chất lượng. Việc của EM là nhận ra pattern này và đẩy hướng tới một tập approver rộng hơn, review rotation, hoặc ủy quyền rõ ràng, để lịch của một người không kìm hãm throughput của cả team.

Đòn bẩy ít được dùng nhất, và đáng nêu ra rõ ràng, là dùng code review như một cơ chế lan truyền kiến thức chứ không chỉ là gác cổng. Ghép PR của một junior engineer với một senior reviewer, hoặc chủ động phân công review chéo team, mang lại nhiều giá trị cho kỹ năng tập thể và bus-factor của team hơn bất kỳ khối lượng đào tạo chính thức nào — và đó là một đòn bẩy chỉ có manager mới ở vị trí để chủ động kéo, vì từng engineer riêng lẻ sẽ mặc định chọn ai nhanh nhất hoặc rảnh nhất.

Chiến lược testing dưới góc nhìn quản lý

Phân loại kỹ thuật — unit, integration, end-to-end, contract test, cuộc tranh luận pyramid vs. trophy — được trình bày trong Testing. Điều EM thực sự quyết định là bao nhiêu thời gian của team đáng để dành cho tầng nào, xét theo hồ sơ rủi ro của thứ họ đang xây dựng.

Đây về cơ bản là một quyết định rủi ro-và-đầu tư, không phải một quyết định kỹ thuật. Một team xây dựng công cụ admin nội bộ dùng bởi năm người có chi phí thất bại chấp nhận được rất khác với một team xây dựng luồng checkout cho sản phẩm thanh toán. Vai trò của manager là làm cho việc phân loại rủi ro đó trở nên rõ ràng thay vì để mỗi engineer tự đoán mức độ cẩn thận cần có:

Bối cảnh	Tư thế chấp nhận được	Vì sao
Công cụ nội bộ, feature ít traffic, thay đổi đảo ngược được	”Move fast, fix forward” — ship sau feature flag, theo dõi, rollback nếu sai	Chi phí một bug thấp và khôi phục được
Bề mặt sản phẩm hướng người dùng cốt lõi	Test coverage tự động vững chắc + rollout theo giai đoạn	Chi phí một regression hiển thị và ảnh hưởng danh tiếng
Thanh toán, billing, đối soát tài chính	Test coverage dày, review bắt buộc, thường có cửa sổ đóng băng thay đổi hoặc sign-off bổ sung	Chi phí một bug là tiền bạc, đôi khi không đảo ngược được
Lĩnh vực bị quản lý (y tế, tuân thủ tài chính, hệ thống an toàn tính mạng)	Kế hoạch test chính thức, audit trail, có thể cần review/chứng nhận bên ngoài	Chi phí một bug có thể là pháp lý hoặc an toàn tính mạng, không chỉ tài chính

“Move fast and fix forward” là một văn hóa engineering chính đáng — nhưng chỉ khi manager đã chủ động quyết định phạm vi ảnh hưởng (blast radius) của thất bại là chấp nhận được. Áp dụng nó đồng loạt, không có sự phân loại rủi ro đó, chính là cách các team gặp phải sự cố production đúng ở những hệ thống mà họ ít có khả năng chịu đựng nhất. Đây là một trong những trường hợp rõ ràng nhất mà phán đoán của EM — chứ không phải sở thích engineering — đặt ra tiêu chuẩn.

Security là việc của tất cả mọi người

Cơ chế kỹ thuật sâu của security practices — SAST/DAST, quét dependency, threat modeling, secure coding, incident response — được trình bày xuyên suốt DevSecOps knowledge base. Trách nhiệm ở tầng quản lý hẹp hơn nhưng khó duy trì hơn: biến security thành thứ cả team sở hữu liên tục, không phải một checklist một người chạy trước mỗi lần release.

Hai điều thuộc hẳn về manager:

• Đưa security dịch sang trái (shift-left) trong thực tế, không chỉ trong khẩu hiệu. Nghĩa là các cân nhắc security (validate input, vệ sinh dependency, xử lý secret, least privilege) là một phần của Definition of Done thực sự của team và xuất hiện trong các cuộc thảo luận thiết kế và code review — không phải gắn thêm như một cuộc audit riêng biệt sau đó. Làm điều này thành hiện thực thường có nghĩa là nhúng một security champion vào team và cho họ thời gian và vị thế rõ ràng để nêu ra các blocker, thay vì hy vọng engineer thấm nhuần tư duy security qua “thẩm thấu”.
• Bảo vệ thời gian cho security work không có lợi ích feature hiển thị. Cập nhật dependency, vá CVE, review quyền truy cập, và các buổi threat modeling không bao giờ xuất hiện như một feature đã ship, nghĩa là chúng là thứ đầu tiên bị cắt dưới áp lực deadline trừ khi manager chủ động bảo vệ một phần capacity cho chúng. Đây là một quyết định ngân sách lặp lại, không phải một chính sách một lần — và là một trong những nơi rõ ràng nhất mà ưu tiên thực tế của một EM (những gì thực sự được lên lịch) quan trọng hơn giá trị tuyên bố của họ (những gì họ nói là quan trọng trong buổi all-hands).

Khái niệm chính

Đặt ra tiêu chuẩn mà không trở thành bottleneck

Căng thẳng mà mọi EM cuối cùng đều gặp phải là: ai đó cần thực thi các practice, nhưng không thể luôn là manager, nếu không manager sẽ trở thành trần giới hạn cho throughput của team. Giải pháp là một mô hình hai tầng:

• EM đặt ra tiêu chuẩn — “CI xanh” nghĩa là gì, SLA review là gì, mức test coverage kỳ vọng cho loại hệ thống nào, Definition of Done về security bao gồm những gì. Đây là chính sách, được quyết định thỉnh thoảng và xem xét lại khi nó không còn phù hợp với thực tế.
• Tech lead và senior engineer thực thi tiêu chuẩn hàng ngày — họ là những người thực sự chặn một PR bỏ qua test, phản đối một thiết kế không có kế hoạch rollback, hay gắn cờ một dependency chưa được vá. Đây là vận hành, diễn ra liên tục, song hành với công việc.

Giao quyền sở hữu chất lượng theo cách này có nghĩa là manager xem xét kết quả của các practice định kỳ — xu hướng sức khỏe pipeline, độ trễ review, postmortem sự cố, tuổi của security backlog — thay vì tự mình xét lại từng quyết định. Anti-pattern cần chú ý ở chính mình là trở thành reviewer hoặc approver cuối cùng trên thực tế cho mọi thứ, điều này không chỉ tạo ra bottleneck mà còn âm thầm nói với senior engineer rằng phán đoán của họ không được tin tưởng — điều ăn mòn sự phát triển của họ và toàn bộ lý do tuyển senior ngay từ đầu.

Đo lường sức khỏe practice: DORA four keys

Chương trình nghiên cứu DORA (DevOps Research and Assessment), được tóm tắt trong Accelerate và các báo cáo State of DevOps thường niên, đã chắt lọc nhiều năm dữ liệu thành bốn chỉ số tương quan với các tổ chức engineering hiệu suất cao. Với một EM, đây là tín hiệu chẩn đoán ở tầng hệ thống, không phải bảng xếp hạng để đánh giá từng engineer cá nhân.

Chỉ số	Đo lường điều gì	Sự suy giảm báo hiệu gì cho manager
Deployment frequency (tần suất deploy)	Team ship lên production bao lâu một lần	Kích thước batch đang lớn dần, ma sát trong quy trình release tăng, hoặc nỗi sợ deploy
Lead time for changes (thời gian từ commit đến production)	Thời gian từ commit đến khi chạy trên production	Bottleneck review, CI chậm/flaky, hoặc ma sát trong chuỗi approval
Change failure rate (tỷ lệ thay đổi gây lỗi)	Phần trăm deployment gây lỗi production	Lỗ hổng testing, chiều sâu review không đủ, hoặc phân loại rủi ro không khớp thực tế
Time to restore service (thời gian khôi phục dịch vụ)	Mất bao lâu để hồi phục sau một sự cố production	Observability yếu, quy trình rollback không rõ ràng, hoặc quyền sở hữu sự cố không rõ ràng

Giá trị của bốn chỉ số này là chúng biến “engineering có khỏe mạnh không?” từ một cảm giác mơ hồ thành một đường xu hướng mà manager có thể hành động. Ví dụ, change failure rate tăng lên là một gợi ý để đi xem xét liệu đầu tư testing hay chiều sâu review có đang âm thầm xói mòn hay không — không phải một lý do để công khai chỉ trích ai đó có deploy gây ra sự cố gần nhất. Dùng tốt, các chỉ số DORA hướng manager đến practice nào cần chú ý; dùng sai, chúng bị gian lận (deployment frequency bị thổi phồng bằng commit vô nghĩa, lead time bị lách bằng cách gộp review) hoặc bị biến thành chỉ số hiệu suất cá nhân, cả hai đều phá hủy mục đích của chúng và làm tổn hại niềm tin. Kết hợp chúng với tín hiệu định tính từ 1:1 và retro — các con số cho bạn biết nên nhìn vào đâu, không phải toàn bộ câu chuyện.

Chi phí dồn tích của nợ practice

Practice yếu không thất bại ầm ĩ ngay ngày đầu; chúng tích tụ âm thầm rồi biểu hiện thành một cuộc khủng hoảng. Đáng để lần theo chuỗi này một cách rõ ràng, vì đó là lý lẽ cho việc tại sao một EM nên đầu tư vào practice trước khi chúng hiển nhiên bị hỏng:

• Một pipeline flaky nuôi dưỡng văn hóa “cứ chạy lại”, nuôi dưỡng niềm tin giả vào build xanh, cuối cùng để lọt một regression thật vì không ai tin tưởng lần mà CI thực sự đúng.
• Một quy trình review chậm hoặc nghẽn nuôi dưỡng batch lớn hơn (vì branch nằm lâu hơn, nên nhiều việc chồng lên nó trước khi merge), nuôi dưỡng những thay đổi khó review hơn, rủi ro hơn — trái ngược hẳn với điều review được thiết kế để tạo ra. Điều này kết nối trực tiếp với các khái niệm work-in-progress và flow trong Agile Process & Delivery.
• Testing đầu tư dưới mức nuôi dưỡng văn hóa chữa cháy, nuôi dưỡng burnout on-call, nuôi dưỡng sự ra đi của chính những senior engineer lẽ ra sẽ sửa lỗ hổng practice cơ bản. Các lựa chọn kiến trúc khiến code khó test ngay từ đầu — được trình bày trong Technical Decision-Making & Architecture — thường nằm ở thượng nguồn của vấn đề này.
• Security work bị trì hoãn nuôi dưỡng một backlog dependency chưa vá và quyền truy cập chưa review đang lớn dần, thứ vô hình cho đến khi nó trở thành một sự cố — lúc đó nó là một khắc phục đắt đỏ hơn nhiều so với khi còn là bảo trì định kỳ.

Trong mọi trường hợp, pattern giống nhau: chi phí bỏ bê một practice bị hoãn lại, không bị tránh khỏi, và nó dồn tích. Đây là lý lẽ mạnh nhất để một EM coi sức khỏe practice là một hạng mục lặp lại trong lập kế hoạch, không phải một dự án dọn dẹp làm một lần mỗi năm.

Tín hiệu cần can thiệp trực tiếp

Hầu hết thời gian, việc giao cho tech lead là đủ. Một EM nên can thiệp trực tiếp hơn khi họ thấy: cùng một stage pipeline hỏng lặp đi lặp lại mà không ai sở hữu việc sửa nó, vi phạm SLA review trở thành chuẩn mực thay vì ngoại lệ, test coverage âm thầm giảm trên một hệ thống vừa được phân loại lại là rủi ro cao hơn, hoặc một security backlog bị hạ ưu tiên xuống dưới feature work trong nhiều chu kỳ lập kế hoạch liên tiếp. Đây là những khoảnh khắc mà “tin tưởng tech lead xử lý” đã ngừng hoạt động và manager cần tự mình đặt lại ưu tiên.

Best Practices

Khu vực practice	Link deep-dive	Trách nhiệm cụ thể của EM
CI/CD	CI/CD	Định nghĩa tiêu chuẩn tốc độ/độ tin cậy; quyết định khi nào cấp ngân sách cho pipeline health work thay vì feature; escalate khi flaky dai dẳng
Code review	Version Control & Collaboration	Đặt chuẩn mực SLA review; ngăn bottleneck từ single-approver; dùng phân công review để lan truyền kiến thức
Testing	Testing	Đặt mức đầu tư testing dựa trên rủi ro của team; quyết định nơi nào “move fast, fix forward” chấp nhận được và nơi nào không
Security	DevSecOps knowledge base	Đưa security vào Definition of Done; bảo vệ ngân sách cho security work vô hình
Luồng delivery	Agile Process & Delivery	Giữ WIP và kích thước batch hợp lý để chất lượng review/testing không xói mòn dưới áp lực flow
Kiến trúc	Technical Decision-Making & Architecture	Đảm bảo các quyết định kiến trúc không âm thầm khiến testing hay deploy an toàn khó hơn

Ngoài bảng trên, một vài thói quen giúp mô hình giám sát này hoạt động tốt trong thực tế:

• Xem xét sức khỏe practice theo nhịp độ, không tùy hứng. Một lần nhìn hàng tháng (hoặc theo chu kỳ release) vào xu hướng DORA, độ trễ review, và tuổi security backlog bắt được sự xuống cấp sớm, trước khi nó thành đám cháy.
• Kết hợp chỉ số với check-in định tính. Một con số di chuyển sai hướng là một gợi ý để hỏi tech lead hoặc team xem chuyện gì đang xảy ra, không phải một phán quyết tự thân.
• Đầu tư dần dần, không phải bằng các “quality sprint”. Một team coi sức khỏe practice là thứ sửa một lần mỗi năm đã thua cuộc tranh luận này rồi; một khoản thuế thời gian nhỏ, đều đặn mỗi chu kỳ rẻ hơn và bền vững hơn các nỗ lực dồn dập theo đợt.
• Đưa tiêu chuẩn vào onboarding. Engineer mới nên học SLA review, kỳ vọng testing, và chuẩn mực security của team trong tuần đầu tiên, không phải phát hiện ra chúng bằng cách bị từ chối một PR vì những lý do không ai nói với họ.
• Cưỡng lại ham muốn trở thành tuyến phòng thủ cuối cùng. Nếu manager là người bắt được thứ lẽ ra các practice phải bắt được, thì chính các practice — không phải sự tận tâm của manager — mới là thứ cần sửa.

Tài liệu tham khảo

• Google Engineering Practices — How to Do a Code Review
• Nicole Forsgren, Jez Humble, Gene Kim — Accelerate: The Science of Lean Software and DevOps
• DORA — State of DevOps Reports and the Four Keys
• Martin Fowler — Continuous Integration
• Google Testing Blog — Test Sizes
• OWASP — DevSecOps Guideline