Được biết, năng lực của CTO chỉ được kiểm tra ở lần thứ XNUMX đảm nhiệm vai trò này. Bởi vì làm việc trong một công ty trong vài năm, cùng phát triển với nó và ở trong cùng một bối cảnh văn hóa, dần dần nhận được nhiều trách nhiệm hơn là một chuyện. Và việc được bổ nhiệm thẳng vào vị trí giám đốc kỹ thuật của một công ty với hành trang kế thừa và hàng loạt vấn đề được giấu gọn gàng lại là một điều hoàn toàn khác.

Theo nghĩa này, trải nghiệm của Leon Fire mà anh ấy đã chia sẻ trên DevOpsConf, không hẳn là độc nhất, nhưng nhân với kinh nghiệm của anh ấy và số lượng vai trò khác nhau mà anh ấy đã thử sức trong suốt 20 năm, nó rất hữu ích. Bên dưới phần cắt là trình tự thời gian của các sự kiện trong 90 ngày và rất nhiều câu chuyện gây cười khi chúng xảy ra với người khác nhưng lại không mấy thú vị khi đối mặt trực tiếp.

Leon nói tiếng Nga rất sặc sỡ, vì vậy nếu bạn có 35-40 phút, tôi khuyên bạn nên xem video. Phiên bản văn bản để tiết kiệm thời gian dưới đây.

Phiên bản đầu tiên của báo cáo là bản mô tả có cấu trúc rõ ràng về cách làm việc với con người và quy trình, bao gồm các khuyến nghị hữu ích. Nhưng cô ấy đã không truyền tải hết những điều bất ngờ gặp phải trên đường đi. Vì vậy, tôi đã thay đổi hình thức và trình bày những vấn đề nảy sinh trước mắt giống như một chiếc hộp độc lập ở công ty mới và các phương pháp giải quyết chúng theo trình tự thời gian.

Một tháng trước

Giống như nhiều câu chuyện hay, câu chuyện này bắt đầu bằng rượu. Chúng tôi đang ngồi với bạn bè trong một quán bar và đúng như dự đoán của các chuyên gia CNTT, mọi người đều than khóc về vấn đề của mình. Một trong số họ vừa mới thay đổi công việc và đang nói về những vấn đề của anh ấy với công nghệ, với con người và với nhóm. Càng lắng nghe, tôi càng nhận ra rằng anh ấy nên thuê tôi, bởi vì đây là những vấn đề mà tôi đã giải quyết trong 15 năm qua. Tôi đã nói với anh ấy như vậy và ngày hôm sau chúng tôi gặp nhau ở môi trường làm việc. Công ty có tên là Chiến lược giảng dạy.

Teaching Strategies là công ty dẫn đầu thị trường về chương trình giảng dạy dành cho trẻ nhỏ từ sơ sinh đến ba tuổi. Công ty “giấy” truyền thống đã có tuổi đời 40 và phiên bản SaaS kỹ thuật số của nền tảng này đã có tuổi đời 10. Gần đây, quá trình điều chỉnh công nghệ kỹ thuật số theo tiêu chuẩn của công ty đã bắt đầu. Phiên bản “mới” ra mắt năm 2017 và gần giống như phiên bản cũ, chỉ có điều nó hoạt động kém hơn.

Điều thú vị nhất là lưu lượng truy cập của công ty này rất dễ đoán - từ ngày này sang ngày khác, từ năm này sang năm khác, bạn có thể dự đoán rất rõ ràng có bao nhiêu người sẽ đến và khi nào. Ví dụ, từ 13 đến 15 giờ chiều, tất cả trẻ em ở trường mẫu giáo đều đi ngủ và giáo viên bắt đầu nhập thông tin. Và điều này xảy ra hàng ngày, trừ cuối tuần, vì hầu như không ai làm việc vào cuối tuần.

Nhìn về phía trước một chút, tôi sẽ lưu ý rằng tôi bắt đầu công việc của mình trong khoảng thời gian có lưu lượng truy cập hàng năm cao nhất, điều này thật thú vị vì nhiều lý do.

Nền tảng dường như chỉ mới 2 tuổi này đã có một nền tảng đặc biệt: ColdFusion & SQL Server từ năm 2008. ColdFusion, nếu bạn không biết, và rất có thể bạn không biết, là một PHP dành cho doanh nghiệp xuất hiện vào giữa những năm 90 và kể từ đó tôi thậm chí còn chưa nghe nói đến nó. Ngoài ra còn có: Ruby, MySQL, PostgreSQL, Java, Go, Python. Nhưng khối nguyên khối chính chạy trên ColdFusion và SQL Server.

Vấn đề

Càng nói chuyện với nhân viên công ty về công việc và những vấn đề gặp phải, tôi càng nhận ra rằng các vấn đề đó không chỉ mang tính chất kỹ thuật. Được rồi, công nghệ đã cũ - và họ không hoạt động được, nhưng có vấn đề với nhóm và quy trình, và công ty bắt đầu hiểu điều này.

Theo truyền thống, các kỹ thuật viên của họ ngồi trong góc và làm một số công việc. Nhưng ngày càng có nhiều hoạt động kinh doanh bắt đầu chuyển sang phiên bản kỹ thuật số. Vì vậy, vào năm cuối trước khi tôi bắt đầu làm việc, công ty đã xuất hiện những người mới: ban giám đốc, CTO, CPO và giám đốc QA. Tức là công ty bắt đầu đầu tư vào lĩnh vực công nghệ.

Dấu vết của một di sản nặng nề không chỉ có trong hệ thống. Công ty có các quy trình kế thừa, con người kế thừa, văn hóa kế thừa. Tất cả điều này đã phải được thay đổi. Tôi nghĩ rằng nó chắc chắn sẽ không nhàm chán và quyết định thử.

Hai ngày trước

Hai ngày trước khi bắt đầu công việc mới, tôi đến văn phòng, điền những thủ tục giấy tờ cuối cùng, gặp nhóm và phát hiện ra lúc đó nhóm đang gặp khó khăn. Đó là thời gian tải trang trung bình đã tăng lên 4 giây, tức là gấp 2 lần.

Đánh giá bằng biểu đồ, rõ ràng có điều gì đó đã xảy ra và không rõ là gì. Hóa ra vấn đề là độ trễ mạng trong trung tâm dữ liệu: độ trễ 5 ms trong trung tâm dữ liệu đã biến thành 2 giây đối với người dùng. Tôi không biết tại sao điều này lại xảy ra, nhưng trong mọi trường hợp, người ta biết rằng vấn đề nằm ở trung tâm dữ liệu.

Ngày đầu tiên

Hai ngày trôi qua và vào ngày đầu tiên đi làm, tôi phát hiện ra rằng vấn đề vẫn chưa biến mất.

Trong hai ngày, các trang của người dùng được tải trung bình trong 4 giây. Tôi hỏi liệu họ có tìm ra vấn đề là gì không.

- Vâng, chúng tôi đã mở một vé.
- và?
- À, họ vẫn chưa trả lời chúng ta.

Sau đó tôi nhận ra rằng tất cả những gì tôi được kể trước đây chỉ là một phần nổi nhỏ của tảng băng chìm mà tôi phải đấu tranh.

Có một câu trích dẫn rất phù hợp với điều này:

“Đôi khi để thay đổi công nghệ bạn phải thay đổi tổ chức.”

Nhưng vì bắt đầu đi làm vào thời điểm bận rộn nhất trong năm nên tôi phải xem xét cả hai phương án để giải quyết vấn đề: cả nhanh chóng và lâu dài. Và bắt đầu với những gì quan trọng ngay bây giờ.

Ngày thứ ba

Vì vậy, quá trình tải kéo dài 4 giây và từ 13 đến 15 là đỉnh lớn nhất.

Vào ngày thứ ba trong khoảng thời gian này, tốc độ tải xuống như sau:

Theo quan điểm của tôi, không có gì hiệu quả cả. Theo quan điểm của những người khác, nó chạy chậm hơn bình thường một chút. Nhưng điều đó không xảy ra như vậy - đó là một vấn đề nghiêm trọng.

Tôi đã cố gắng thuyết phục nhóm và họ trả lời rằng họ chỉ cần nhiều máy chủ hơn. Tất nhiên, đây là giải pháp cho vấn đề nhưng không phải lúc nào cũng là giải pháp duy nhất và hiệu quả nhất. Tôi hỏi tại sao không có đủ máy chủ, lưu lượng truy cập là bao nhiêu. Tôi đã ngoại suy dữ liệu và nhận thấy rằng chúng tôi có khoảng 150 yêu cầu mỗi giây, về nguyên tắc, nằm trong giới hạn hợp lý.

Nhưng chúng ta không được quên rằng trước khi có được câu trả lời đúng, bạn cần phải đặt câu hỏi đúng. Câu hỏi tiếp theo của tôi là: chúng ta có bao nhiêu máy chủ giao diện người dùng? Câu trả lời “làm tôi hơi bối rối” - chúng tôi có 17 máy chủ giao diện người dùng!

— Tôi xấu hổ khi hỏi, nhưng 150 chia cho 17 được bằng 8? Ý bạn là mỗi máy chủ cho phép 8 yêu cầu mỗi giây và nếu ngày mai có 160 yêu cầu mỗi giây thì chúng ta sẽ cần thêm 2 máy chủ phải không?

Tất nhiên, chúng tôi không cần thêm máy chủ. Giải pháp nằm ở chính mã và bề ngoài:

var currentClass = classes.getCurrentClass();
return currentClass;

Đã có một chức năng getCurrentClass(), bởi vì mọi thứ trên trang web đều hoạt động trong ngữ cảnh của một lớp - đúng vậy. Và đối với chức năng này trên mỗi trang có Hơn 200 yêu cầu.

Giải pháp theo cách này rất đơn giản, bạn thậm chí không phải viết lại bất cứ điều gì: chỉ cần không yêu cầu thông tin tương tự nữa.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Tôi rất vui vì tôi quyết định rằng chỉ trong ngày thứ ba tôi đã tìm ra vấn đề chính. Dù tôi còn ngây thơ nhưng đây chỉ là một trong nhiều vấn đề.

Nhưng việc giải quyết vấn đề đầu tiên này đã khiến biểu đồ tụt xuống thấp hơn nhiều.

Đồng thời, chúng tôi đang thực hiện các tối ưu hóa khác. Có rất nhiều thứ trước mắt có thể sửa được. Ví dụ, vào cùng ngày thứ ba, tôi phát hiện ra rằng có một bộ đệm trong hệ thống (lúc đầu tôi nghĩ rằng tất cả các yêu cầu đều đến trực tiếp từ cơ sở dữ liệu). Khi tôi nghĩ đến bộ đệm, tôi nghĩ đến Redis hoặc Memcached tiêu chuẩn. Nhưng tôi là người duy nhất nghĩ như vậy, bởi vì hệ thống đó sử dụng MongoDB và SQL Server để lưu vào bộ đệm - chính là hệ thống mà dữ liệu vừa được đọc.

Ngày thứ mười

Tuần đầu tiên tôi phải giải quyết những vấn đề cần giải quyết ngay bây giờ. Ở đâu đó trong tuần thứ hai, lần đầu tiên tôi đến chỗ đứng để giao tiếp với nhóm, để xem điều gì đang xảy ra và toàn bộ quá trình diễn ra như thế nào.

Một điều thú vị lại được phát hiện. Nhóm bao gồm: 18 nhà phát triển; 8 người thử nghiệm; 3 người quản lý; 2 kiến trúc sư. Và tất cả họ đều tham gia vào các nghi lễ chung, tức là mỗi sáng có hơn 30 người đứng dậy và kể lại những gì họ đã làm. Rõ ràng là cuộc họp không kéo dài 5 hoặc 15 phút. Không ai lắng nghe ai vì mọi người đều làm việc trên các hệ thống khác nhau. Với hình thức này, 2-3 vé mỗi giờ cho một buổi chải lông đã là một kết quả tốt.

Điều đầu tiên chúng tôi làm là chia nhóm thành nhiều dòng sản phẩm. Đối với các phần và hệ thống khác nhau, chúng tôi đã phân bổ các nhóm riêng biệt, bao gồm nhà phát triển, người thử nghiệm, người quản lý sản phẩm và nhà phân tích kinh doanh.

Kết quả là chúng tôi đã nhận được:

Giảm tình trạng đứng lên và biểu tình.
Kiến thức chuyên môn về sản phẩm.
Một cảm giác sở hữu. Khi mọi người thường xuyên mày mò các hệ thống, họ biết rằng rất có thể người khác sẽ phải xử lý các lỗi của họ chứ không phải chính họ.
Hợp tác giữa các nhóm. Không cần phải nói, trước đây QA không giao tiếp nhiều với các lập trình viên, sản phẩm đã làm việc riêng của nó, v.v. Bây giờ họ có một điểm chung về trách nhiệm.

Chúng tôi chủ yếu tập trung vào hiệu quả, năng suất và chất lượng - đây là những vấn đề chúng tôi cố gắng giải quyết thông qua quá trình chuyển đổi đội ngũ.

Ngày mười một

Trong quá trình thay đổi cơ cấu đội, tôi phát hiện ra cách tính Câu chuyệnĐiểm. 1 SP tương đương với một ngày và mỗi vé chứa SP cho cả quá trình phát triển và QA, tức là ít nhất 2 SP.

Làm thế nào tôi phát hiện ra điều này?

Chúng tôi đã tìm thấy một lỗi: trong một trong các báo cáo, trong đó ngày bắt đầu và ngày kết thúc của khoảng thời gian cần báo cáo được nhập, ngày cuối cùng không được tính đến. Nghĩa là, ở đâu đó trong yêu cầu không có <=, mà chỉ đơn giản là <. Tôi được bảo rằng đây là ba Điểm câu chuyện, nghĩa là 3 ngày.

Sau này chúng tôi:

Hệ thống xếp hạng Story Points đã được sửa đổi. Giờ đây, các bản sửa lỗi nhỏ có thể nhanh chóng được chuyển qua hệ thống sẽ đến tay người dùng nhanh hơn.
Chúng tôi bắt đầu hợp nhất các vé liên quan để phát triển và thử nghiệm. Trước đây, mỗi tấm vé, mỗi bug đều là một hệ sinh thái khép kín, không bị ràng buộc với bất cứ thứ gì khác. Việc thay đổi ba nút trên một trang có thể là ba phiếu khác nhau với ba quy trình QA khác nhau thay vì một bài kiểm tra tự động trên mỗi trang.
Chúng tôi bắt đầu làm việc với các nhà phát triển về phương pháp ước tính chi phí lao động. Ba ngày thay một nút thì không vui chút nào.

Ngày thứ hai mươi

Đâu đó vào giữa tháng đầu tiên, tình hình ổn định hơn một chút, tôi nhận ra về cơ bản điều gì đang xảy ra và bắt đầu nhìn về tương lai và nghĩ về các giải pháp lâu dài.

Mục tiêu dài hạn:

Nền tảng được quản lý. Hàng trăm yêu cầu trên mỗi trang đều không nghiêm trọng.
Những xu hướng có thể dự đoán được. Có những đỉnh điểm lưu lượng truy cập định kỳ mà thoạt nhìn không tương quan với các số liệu khác - chúng tôi cần hiểu lý do tại sao điều này xảy ra và học cách dự đoán.
Mở rộng nền tảng. Việc kinh doanh không ngừng phát triển, ngày càng có nhiều người dùng đến và lưu lượng truy cập ngày càng tăng.

Ngày xưa người ta thường nói: “Hãy viết lại mọi thứ bằng [ngôn ngữ/framework], mọi thứ sẽ hoạt động tốt hơn!”

Trong hầu hết các trường hợp, điều này không hiệu quả, thật tốt nếu việc viết lại có hiệu quả. Vì vậy, chúng tôi cần tạo ra một lộ trình - một chiến lược cụ thể minh họa từng bước cách đạt được các mục tiêu kinh doanh (chúng tôi sẽ làm gì và tại sao), trong đó:

phản ánh sứ mệnh và mục tiêu của dự án;
ưu tiên các mục tiêu chính;
chứa một lịch trình để đạt được chúng.

Trước đó, chưa có ai nói chuyện với nhóm về mục đích của bất kỳ thay đổi nào được thực hiện. Điều này đòi hỏi các thước đo thành công phù hợp. Lần đầu tiên trong lịch sử công ty, chúng tôi đặt KPI cho nhóm kỹ thuật và các chỉ số này gắn liền với các chỉ số của tổ chức.

Nghĩa là, KPI của tổ chức được hỗ trợ bởi các nhóm và KPI của nhóm được hỗ trợ bởi KPI của từng cá nhân. Ngược lại, nếu KPI công nghệ không trùng với KPI của tổ chức, thì mọi người sẽ tự kéo chăn lên.

Ví dụ: một trong những KPI của tổ chức là tăng thị phần thông qua các sản phẩm mới.

Làm thế nào bạn có thể hỗ trợ mục tiêu có nhiều sản phẩm mới hơn?

Đầu tiên, chúng tôi muốn dành nhiều thời gian hơn để phát triển sản phẩm mới thay vì sửa lỗi. Đây là một giải pháp hợp lý và dễ đo lường.
Thứ hai, chúng tôi muốn hỗ trợ việc tăng khối lượng giao dịch, vì thị phần càng lớn thì càng có nhiều người dùng và theo đó, lưu lượng truy cập càng nhiều.

Sau đó, các KPI riêng lẻ có thể được thực hiện trong nhóm chẳng hạn sẽ ở vị trí phát sinh những khiếm khuyết chính. Nếu bạn tập trung cụ thể vào phần này, bạn có thể đảm bảo rằng có ít sai sót hơn nhiều và khi đó thời gian phát triển sản phẩm mới cũng như thời gian hỗ trợ các KPI của tổ chức sẽ tăng lên.

Vì vậy, mọi quyết định, bao gồm cả việc viết lại mã, đều phải hỗ trợ các mục tiêu cụ thể mà công ty đã đặt ra cho chúng ta (tăng trưởng tổ chức, tính năng mới, tuyển dụng).

Trong quá trình này, một điều thú vị đã được đưa ra ánh sáng, điều này đã trở thành tin tức không chỉ đối với giới công nghệ mà còn trong công ty nói chung: tất cả các yêu cầu phải tập trung vào ít nhất một KPI. Nghĩa là, nếu một sản phẩm nói rằng nó muốn tạo một tính năng mới, thì câu hỏi đầu tiên nên được đặt ra là: “Tính năng này hỗ trợ KPI gì?” Nếu không thì xin lỗi - nó có vẻ như là một tính năng không cần thiết.

Ngày thứ ba mươi

Vào cuối tháng, tôi phát hiện ra một sắc thái khác: chưa có ai trong nhóm Vận hành của tôi từng xem các hợp đồng mà chúng tôi ký kết với khách hàng. Bạn có thể hỏi tại sao bạn cần xem danh bạ.

Thứ nhất, vì SLA được quy định trong hợp đồng.
Thứ hai, SLA đều khác nhau. Mỗi khách hàng đưa ra yêu cầu riêng, bộ phận kinh doanh ký mà không cần xem xét.

Một sắc thái thú vị khác là hợp đồng với một trong những khách hàng lớn nhất quy định rằng tất cả các phiên bản phần mềm được nền tảng hỗ trợ phải là n-1, nghĩa là không phải phiên bản mới nhất mà là phiên bản áp chót.

Rõ ràng là chúng ta đã tiến xa đến mức n-1 bao xa nếu nền tảng dựa trên ColdFusion và SQL Server 2008, những nền tảng này hoàn toàn không còn được hỗ trợ vào tháng XNUMX.

Ngày thứ bốn mươi lăm

Khoảng giữa tháng thứ hai tôi có đủ thời gian để ngồi xuống và làm giá trịdònglập bản đồ hoàn toàn cho toàn bộ quá trình. Đây là những bước cần thiết cần được thực hiện, từ việc tạo ra sản phẩm đến giao sản phẩm đến tay người tiêu dùng và chúng cần được mô tả càng chi tiết càng tốt.

Bạn chia quy trình thành nhiều phần nhỏ và xem điều gì đang chiếm quá nhiều thời gian, điều gì có thể được tối ưu hóa, cải thiện, v.v. Ví dụ: mất bao lâu để một yêu cầu sản phẩm được hoàn thiện, khi nào nó đạt được yêu cầu mà nhà phát triển có thể thực hiện, QA, v.v. Vì vậy, bạn xem xét chi tiết từng bước riêng lẻ và suy nghĩ về những gì có thể được tối ưu hóa.

Khi tôi làm điều này, có hai điều khiến tôi chú ý:

tỷ lệ vé cao được trả lại từ QA cho nhà phát triển;
quá trình xem xét yêu cầu kéo mất quá nhiều thời gian.

Vấn đề là đây là những kết luận như: Có vẻ mất rất nhiều thời gian, nhưng chúng tôi không chắc là bao lâu.

"Bạn không thể cải thiện những gì bạn không thể đo lường được."

Làm thế nào để biện minh cho vấn đề nghiêm trọng như thế nào? Liệu nó lãng phí ngày hay giờ?

Để đo lường điều này, chúng tôi đã thêm một số bước vào quy trình Jira: “sẵn sàng cho nhà phát triển” và “sẵn sàng cho QA” để đo lường thời gian mỗi yêu cầu chờ đợi và số lần nó quay lại một bước nhất định.

Chúng tôi cũng đã thêm "đang xem xét" để biết trung bình có bao nhiêu vé để xem xét và từ đó bạn có thể bắt đầu nhảy múa. Chúng tôi đã có số liệu hệ thống, bây giờ chúng tôi đã thêm số liệu mới và bắt đầu đo lường:

Hiệu quả quá trình: hiệu suất và kế hoạch/chuyển giao.
Chất lượng quy trình: số lượng khuyết điểm, khuyết điểm từ QA.

Nó thực sự giúp hiểu được điều gì đang diễn ra tốt đẹp và điều gì không suôn sẻ.

Ngày thứ năm mươi

Tất nhiên, tất cả điều này đều hay và thú vị, nhưng vào cuối tháng thứ hai, có một điều gì đó đã xảy ra mà về nguyên tắc là có thể đoán trước được, mặc dù tôi không mong đợi một quy mô như vậy. Mọi người bắt đầu rời đi vì ban lãnh đạo cấp cao đã thay đổi. Những người mới tham gia quản lý và bắt đầu thay đổi mọi thứ, còn những người cũ thì nghỉ việc. Và thông thường trong một công ty đã được vài năm, mọi người đều là bạn bè và mọi người đều biết nhau.

Điều này đã được dự đoán trước, nhưng quy mô của việc sa thải thật bất ngờ. Ví dụ, trong một tuần, hai trưởng nhóm đồng thời nộp đơn từ chức theo ý chí tự do của họ. Vì vậy, tôi không những phải quên đi những vấn đề khác mà còn phải tập trung vào tạo ra một đội. Đây là một vấn đề lâu dài và khó giải quyết, nhưng nó phải được giải quyết vì tôi muốn cứu những người còn lại (hoặc hầu hết trong số họ). Cần phải phản ứng bằng cách nào đó trước việc mọi người rời đi để duy trì tinh thần trong đội.

Về lý thuyết, điều này là tốt: một người mới đến có toàn quyền quyết định, người có thể đánh giá kỹ năng của nhóm và thay thế nhân sự. Trên thực tế, bạn không thể chỉ thu hút người mới vì nhiều lý do. Sự cân bằng luôn luôn cần thiết.

Cũ và mới. Chúng ta cần giữ lại những người già có thể thay đổi và hỗ trợ sứ mệnh. Nhưng đồng thời, chúng ta cần mang lại dòng máu mới, chúng ta sẽ nói về điều đó sau.
Kinh nghiệm. Tôi đã nói chuyện rất nhiều với những hậu bối giỏi, những người rất háo hức và muốn làm việc cùng chúng tôi. Nhưng tôi không thể nhận họ vì không có đủ tiền bối để hỗ trợ các hậu bối và làm cố vấn cho họ. Đầu tiên cần phải tuyển người giỏi nhất và sau đó mới tuyển được thanh niên.
Cà rốt và cây gậy.

Tôi không có câu trả lời hay cho câu hỏi thế nào là sự cân bằng phù hợp, làm thế nào để duy trì nó, giữ được bao nhiêu người và đẩy bao nhiêu người. Đây là một quá trình hoàn toàn cá nhân.

Ngày thứ năm mươi mốt

Tôi bắt đầu nhìn kỹ vào đội để hiểu mình có ai, và một lần nữa tôi nhớ ra:

“Hầu hết các vấn đề đều là vấn đề về con người.”

Tôi nhận thấy rằng nhóm - cả Dev và Ops - đều có ba vấn đề lớn:

Sự hài lòng với tình trạng hiện tại.
Thiếu trách nhiệm - bởi vì chưa có ai đem kết quả lao động của người thực hiện để ảnh hưởng đến doanh nghiệp.
Sợ thay đổi.

Sự thay đổi luôn đưa bạn ra khỏi vùng an toàn của mình, và càng trẻ, họ càng không thích sự thay đổi vì không hiểu tại sao và không hiểu bằng cách nào. Câu trả lời phổ biến nhất mà tôi từng nghe là: “Chúng tôi chưa bao giờ làm điều đó”. Hơn nữa, nó đã đạt đến mức hoàn toàn vô lý - những thay đổi nhỏ nhất không thể diễn ra nếu không có ai đó phẫn nộ. Và cho dù những thay đổi có ảnh hưởng đến công việc của họ đến mức nào thì mọi người vẫn nói: “Không, tại sao? Nó sẽ không hoạt động."

Nhưng bạn không thể trở nên tốt hơn nếu không thay đổi bất cứ điều gì.

Tôi đã có một cuộc trò chuyện hoàn toàn vô lý với một nhân viên, tôi nói với anh ấy những ý tưởng tối ưu hóa của mình và anh ấy nói với tôi:
- Ồ, bạn không thấy những gì chúng tôi có năm ngoái!
- Vậy thì sao?
“Bây giờ thì đỡ hơn xưa nhiều rồi.”
- Thế thì không thể khá hơn được nữa à?
- Để làm gì?

Câu hỏi hay - tại sao? Cứ như thể bây giờ tốt hơn trước thì mọi thứ đều đủ tốt. Điều này dẫn tới việc thiếu trách nhiệm, về nguyên tắc là hoàn toàn bình thường. Như tôi đã nói, nhóm kỹ thuật có chút đứng ngoài cuộc. Công ty tin rằng họ nên tồn tại, nhưng không ai đặt ra tiêu chuẩn. Bộ phận hỗ trợ kỹ thuật chưa bao giờ thấy SLA, vì vậy nó khá “chấp nhận được” đối với nhóm (và điều này khiến tôi ấn tượng nhất):

Tải 12 giây;
Thời gian ngừng hoạt động 5-10 phút mỗi lần phát hành;
Việc khắc phục sự cố nghiêm trọng phải mất nhiều ngày, nhiều tuần;
thiếu nhân viên túc trực 24x7/theo yêu cầu.

Chưa ai từng hỏi tại sao chúng ta không làm điều đó tốt hơn, và chưa ai nhận ra rằng mọi chuyện không nhất thiết phải như vậy.

Như một phần thưởng, có thêm một vấn đề nữa: thiếu kinh nghiệm. Những đàn anh đã ra đi, đội trẻ còn lại lớn lên dưới chế độ cũ và bị đầu độc bởi nó.

Trên hết, mọi người còn sợ thất bại và tỏ ra kém cỏi. Điều này được thể hiện ở chỗ, trước hết, họ trong mọi trường hợp không yêu cầu giúp đỡ. Đã bao nhiêu lần chúng ta nói chuyện với tư cách nhóm và cá nhân, và tôi đã nói: “Hãy đặt câu hỏi nếu bạn không biết cách làm điều gì đó”. Tôi tự tin vào bản thân và biết rằng mình có thể giải quyết mọi vấn đề nhưng sẽ mất thời gian. Vì thế nếu nhờ ai biết giải trong 10 phút thì mình sẽ hỏi. Càng có ít kinh nghiệm, bạn càng ngại hỏi vì nghĩ mình sẽ bị cho là không đủ năng lực.

Nỗi sợ đặt câu hỏi này thể hiện theo những cách thú vị. Ví dụ, bạn hỏi: “Bạn thực hiện nhiệm vụ này thế nào?” - “Còn vài tiếng nữa thôi, tôi sắp xong rồi.” Ngày hôm sau bạn hỏi lại, bạn nhận được câu trả lời rằng mọi thứ đều ổn, nhưng có một vấn đề, nó chắc chắn sẽ sẵn sàng vào cuối ngày. Một ngày nữa trôi qua, cho đến khi bạn bị ghim vào tường và buộc phải nói chuyện với ai đó, điều này vẫn tiếp tục. Một người muốn tự mình giải quyết vấn đề, anh ta tin rằng nếu anh ta không tự mình giải quyết thì đó sẽ là một thất bại lớn.

Đó là lý do các nhà phát triển đã thổi phồng ước tính. Cũng chính giai thoại đó, khi họ đang bàn bạc về một nhiệm vụ nào đó, họ đưa ra cho tôi một con số như vậy khiến tôi rất ngạc nhiên. Tôi được biết rằng trong ước tính của nhà phát triển, nhà phát triển đã bao gồm thời gian mà phiếu sẽ được trả lại từ QA, bởi vì họ sẽ tìm thấy lỗi ở đó và thời gian PR sẽ diễn ra cũng như thời gian trong khi những người nên xem xét nó sẽ bận rộn - nghĩa là mọi thứ, bất cứ điều gì có thể.

Thứ hai, những người sợ tỏ ra kém cỏi phân tích tổng thể. Khi bạn nói chính xác những gì cần phải làm, nó sẽ bắt đầu: “Không, nếu chúng ta nghĩ về nó ở đây thì sao?” Theo nghĩa này, công ty của chúng tôi không phải là duy nhất; đây là một vấn đề tiêu chuẩn đối với những người trẻ tuổi.

Để đáp lại, tôi đã giới thiệu các phương pháp thực hành sau:

Quy tắc 30 phút. Nếu bạn không thể giải quyết vấn đề trong nửa giờ, hãy nhờ ai đó giúp đỡ. Điều này có hiệu quả với những mức độ thành công khác nhau, bởi vì mọi người vẫn không hỏi, nhưng ít nhất thì quá trình này đã bắt đầu.
Loại bỏ mọi thứ trừ bản chất, khi ước tính thời hạn hoàn thành một nhiệm vụ, nghĩa là chỉ xem xét sẽ mất bao lâu để viết mã.
Học liên tục dành cho những người phân tích quá mức. Đó chỉ là công việc liên tục với mọi người.

Ngày thứ sáu mươi

Trong khi tôi đang làm tất cả những việc này, đã đến lúc phải tính toán ngân sách. Tất nhiên, tôi tìm thấy rất nhiều điều thú vị ở nơi chúng tôi tiêu tiền. Ví dụ: chúng tôi có toàn bộ giá đỡ trong một trung tâm dữ liệu riêng biệt với một máy chủ FTP được sử dụng bởi một khách hàng. Hóa ra “… chúng tôi chuyển đi, nhưng anh ấy vẫn như vậy, chúng tôi không thay đổi anh ấy”. Đó là 2 năm trước.

Điều đặc biệt quan tâm là dự luật về dịch vụ đám mây. Tôi tin rằng lý do chính khiến hóa đơn đám mây cao là do các nhà phát triển lần đầu tiên trong đời có quyền truy cập không giới hạn vào máy chủ. Họ không cần phải hỏi: “Xin hãy cho tôi một máy chủ thử nghiệm”, họ có thể tự mình lấy. Thêm vào đó, các nhà phát triển luôn muốn xây dựng một hệ thống tuyệt vời đến mức Facebook và Netflix sẽ phải ghen tị.

Nhưng các nhà phát triển không có kinh nghiệm trong việc mua máy chủ và kỹ năng xác định kích thước yêu cầu của máy chủ, vì trước đây họ không cần đến nó. Và họ thường không hiểu rõ sự khác biệt giữa khả năng mở rộng và hiệu suất.

Kết quả kiểm kê:

Chúng tôi rời khỏi cùng một trung tâm dữ liệu.
Chúng tôi đã chấm dứt hợp đồng với 3 dịch vụ đăng nhập. Bởi vì chúng tôi có 5 người trong số họ - mọi nhà phát triển bắt đầu chơi với thứ gì đó đều lấy một cái mới.
7 hệ thống AWS đã ngừng hoạt động. Một lần nữa, không ai dừng các dự án đã chết; tất cả họ vẫn tiếp tục làm việc.
Giảm chi phí phần mềm tới 6 lần.

Ngày thứ bảy mươi lăm

Thời gian trôi qua, hai tháng rưỡi nữa tôi phải gặp ban giám đốc. Ban giám đốc của chúng tôi không tốt hơn hay kém hơn những người khác; giống như tất cả các ban giám đốc khác, họ muốn biết mọi thứ. Mọi người đầu tư tiền và muốn biết những gì chúng tôi làm phù hợp với KPI đã đặt ra đến mức nào.

Ban giám đốc nhận được rất nhiều thông tin mỗi tháng: số lượng người dùng, mức tăng trưởng của họ, họ sử dụng dịch vụ gì và như thế nào, hiệu suất và năng suất, và cuối cùng là tốc độ tải trang trung bình.

Vấn đề duy nhất là tôi tin rằng mức trung bình là tội ác thuần túy. Nhưng rất khó để giải thích điều này với ban giám đốc. Họ đã quen với việc hoạt động với các con số tổng hợp chứ không phải là sự trải rộng thời gian tải mỗi giây.

Có một số điểm thú vị về vấn đề này. Ví dụ: tôi đã nói rằng chúng ta cần phân chia lưu lượng truy cập giữa các máy chủ web riêng biệt tùy thuộc vào loại nội dung.

Nghĩa là, ColdFusion đi qua Jetty và nginx và khởi chạy các trang. Còn hình ảnh, JS và CSS đi qua một nginx riêng biệt với cấu hình riêng. Đây là một cách thực hành khá chuẩn mà tôi đang nói đến tôi đã viết một vài năm trước đây. Kết quả là hình ảnh tải nhanh hơn nhiều và... tốc độ tải trung bình đã tăng thêm 200 mili giây.

Điều này xảy ra vì biểu đồ được xây dựng dựa trên dữ liệu đi kèm với Jetty. Nghĩa là, nội dung nhanh không được đưa vào tính toán - giá trị trung bình đã tăng vọt. Điều này đối với chúng tôi là rõ ràng, chúng tôi đã cười, nhưng làm sao chúng tôi có thể giải thích với ban giám đốc tại sao chúng tôi đã làm điều gì đó và mọi thứ trở nên tồi tệ hơn 12%?

Ngày thứ tám mươi lăm

Đến cuối tháng thứ ba, tôi nhận ra có một thứ tôi chưa từng tính tới: thời gian. Mọi thứ tôi nói đều cần có thời gian.

Đây là lịch hàng tuần thực sự của tôi - chỉ một tuần làm việc, không bận lắm. Không có đủ thời gian cho mọi thứ. Vì vậy, một lần nữa, bạn cần tuyển dụng những người có thể giúp bạn giải quyết vấn đề.

Kết luận

Đó chưa phải là tất cả. Trong câu chuyện này, tôi thậm chí còn chưa biết cách chúng tôi làm việc với sản phẩm và cố gắng bắt kịp làn sóng chung, cách chúng tôi tích hợp hỗ trợ kỹ thuật hoặc cách chúng tôi giải quyết các vấn đề kỹ thuật khác. Ví dụ, tôi khá tình cờ biết được rằng trên các bảng lớn nhất trong cơ sở dữ liệu, chúng tôi không sử dụng SEQUENCE. Chúng tôi có một chức năng tự viết nextIDvà nó không được sử dụng trong giao dịch.

Còn hàng triệu điều tương tự nữa mà chúng tôi có thể nói đến trong một thời gian dài. Nhưng điều quan trọng nhất vẫn cần phải nói đến đó là văn hóa.

Chính văn hóa hoặc sự thiếu văn hóa sẽ dẫn đến mọi vấn đề khác. Chúng tôi đang cố gắng xây dựng một nền văn hóa nơi mọi người:

không sợ thất bại;
học hỏi từ những sai lầm;
cộng tác với các đội khác;
Chủ động;
chịu trách nhiệm;
đón nhận kết quả như một mục tiêu;
ăn mừng thành công.

Với điều này mọi thứ khác sẽ đến.

Leon lửa trên Twitter, Facebook và trung bình.

Có hai chiến lược liên quan đến di sản: tránh làm việc với nó bằng mọi giá hoặc dũng cảm vượt qua những khó khăn liên quan. Chúng tôi c DevOpsConf Chúng tôi đang đi theo con đường thứ hai, thay đổi quy trình và cách tiếp cận. Tham gia cùng chúng tôi youtube, danh sách gửi thư и điện tínvà cùng nhau chúng ta sẽ triển khai văn hóa DevOps.

Nguồn: www.habr.com

Kế thừa các hệ thống và quy trình cũ hoặc 90 ngày đầu tiên với tư cách là CTO