Kristin Isaac, Giám đốc điều hành và Đồng sáng lập tại Strudel – Loạt phỏng vấn

Kristin Isaac, Giám đốc điều hành và Đồng sáng lập tại Strudel là một nhà lãnh đạo công nghệ doanh nghiệp kỳ cựu, người đã từng giữ các vị trí cấp cao tại LinkedIn, Udemy, ESPN và Disney trước khi thành lập Strudel. Cô hiện đang tập trung vào việc giải quyết một trong những điểm ma sát lớn nhất trong các tổ chức phần mềm: khoảng cách giữa hỗ trợ khách hàng và kỹ thuật. Tại Strudel, cô đang xây dựng một nền tảng được thúc đẩy động bởi trí tuệ nhân tạo giúp các đội hỗ trợ kỹ thuật giải quyết các vấn đề phức tạp nhanh hơn bằng cách kết nối trực tiếp các yêu cầu hỗ trợ với thông tin kỹ thuật.

Strudel là một nền tảng trí tuệ nhân tạo được thiết kế để tự động hóa hỗ trợ kỹ thuật tiên tiến bằng cách phân tích nhật ký, dữ liệu sản xuất, kho mã và lịch sử hỗ trợ trước đây để xác định nguyên nhân gốc rễ và đề xuất giải pháp. Mục tiêu của nó là giảm thời gian và công sức kỹ thuật cần thiết để giải quyết các trường hợp hỗ trợ khó khăn, đặc biệt là những trường hợp thường tiêu thụ tài nguyên kỹ thuật cao cấp. Bằng cách liên kết hỗ trợ trực tiếp với các vấn đề kỹ thuật cơ bản, Strudel đang định vị mình như một công cụ có thể làm cho hoạt động hỗ trợ doanh nghiệp nhanh hơn, hiệu quả hơn và có thể mở rộng hơn.

Bạn đã từng giữ các vị trí lãnh đạo tại các tổ chức như LinkedIn, Udemy và Disney trước khi thành lập Strudel vào năm 2025. Những kinh nghiệm từ những vị trí đó đã thuyết phục bạn rằng các đội kỹ thuật cần một loại nền tảng “trí tuệ kỹ thuật” mới được hỗ trợ bởi trí tuệ nhân tạo, và làm thế nào cái nhìn sâu sắc đó đã định hình việc thành lập Strudel?

Mỗi công ty tôi làm việc đều có một phiên bản khác nhau của cùng một vấn đề. Tại Disney, những rủi ro là rất lớn – nếu một nền tảng phát trực tuyến gặp sự cố trong một lần ra mắt lớn, nó không chỉ là một tổn thất doanh thu, mà còn là một khoảnh khắc thương hiệu. Tại LinkedIn, quy mô là không ngừng. Có hàng nghìn dịch vụ đều tạo ra tiếng ồn, và ngay cả những đội tốt nhất cũng khó theo kịp. Tại Udemy, tôi đã thấy một đội tinh gọn làm việc anh hùng với công cụ hạn chế.

Cái kết nối tất cả ba và với kinh nghiệm của các đồng sáng lập, Shai Rubin và Brian Kaufman, lãnh đạo các đội kỹ thuật, là rằng các kỹ sư đang dành nhiều thời gian hơn để xây dựng lại ngữ cảnh hơn là giải quyết vấn đề. Ai đó được gọi vào lúc 2 giờ sáng, và trước khi họ có thể bắt đầu chẩn đoán, họ phải tìm kiếm qua các luồng Slack, bảng điều khiển, vé Jira, nhật ký triển khai – chỉ để hiểu những gì đã thay đổi và khi nào. Về cơ bản, họ đang chơi thám tử trước khi họ có thể làm công việc thực sự của mình. Đó là một sự lãng phí tài năng kỹ sư đáng kinh ngạc.

Tôi luôn nghĩ: phải có một cách thông minh hơn để đưa ra những gì thực sự quan trọng, khi nào quan trọng. Đó thực sự là hạt giống của Strudel.

Nhiều công ty đo lường tác động tài chính của thời gian ngừng hoạt động theo doanh thu bị mất hoặc phạt SLA. Trong kinh nghiệm của bạn, những chi phí không nhìn thấy của thời gian ngừng hoạt động mà các tổ chức thường đánh giá thấp là gì?

Số tiền doanh thu làm cho nó vào bản trình bày hội đồng quản trị, nhưng tác động doanh thu ngay lập tức chỉ là một phần nhỏ của những gì thời gian ngừng hoạt động thực sự chi phí. Những thứ tôi đã thấy các tổ chức thường xuyên bỏ qua thuộc vào một số nhóm.

Thứ nhất là niềm tin của khách hàng. Phạt SLA là một cấu trúc pháp lý – chúng không bắt được khách hàng im lặng rời đi, hoặc khách hàng doanh nghiệp tiềm năng nhìn thấy trang trạng thái của bạn vào thời điểm sai và chọn một đối thủ cạnh tranh. Thiệt hại đó là chậm, vô hình và vĩnh viễn theo cách mà một séc hoàn trả đơn giản không phải là.

Thứ hai là sự rời bỏ và kiệt sức của kỹ sư. Mệt mỏi khi gọi là có thực. Khi các kỹ sư giỏi nhất của bạn bị kéo vào các sự cố căng thẳng – đặc biệt là những sự cố có thể đã được ngăn chặn – họ bắt đầu đặt câu hỏi liệu đây có phải là nơi đúng để xây dựng sự nghiệp của họ. Thay thế một kỹ sư cấp cao có chi phí từ một đến hai lần lương hàng năm của họ khi bạn tính đến việc tuyển dụng, giới thiệu và kiến thức tổ chức bị mất. Không ai đưa điều đó vào bản phân tích sau sự cố.

Thứ ba là chi phí cơ hội. Mỗi giờ một đội kỹ thuật dành để chiến đấu với lửa là một giờ không dành để xây dựng sản phẩm. Điều đó khó đưa vào bảng tính, nhưng khi tích lũy trong nhiều tháng, nó im lặng làm hỏng đường dây của bạn.

Kỹ sư thường bị kéo ra khỏi việc xây dựng tính năng mới để phản hồi các sự cố sản xuất. Việc chữa cháy liên tục này ảnh hưởng đến sự đổi mới sản phẩm và đường lối phát triển lâu dài như thế nào?

Nó tạo ra một loại thuế trên khả năng xây dựng của đội kỹ thuật. Mỗi đội có một lượng băng thông hữu hạn, và khi một lượng đáng kể trong đó liên tục bị chuyển hướng đến các sự cố, thì hiệu ứng tổng hợp đối với sự phát triển sản phẩm là nghiêm trọng. Cam kết về đường lối bị bỏ lỡ. Nợ kỹ thuật không được trả. Tính năng được vận chuyển với ít nghiêm ngặt hơn vì có áp lực để bù lại thời gian bị mất.

Cái đặc biệt có hại là sự không thể đoán trước của nó. Một đội có thể lên kế hoạch cho sprint của họ với ý định tốt, và sau đó một sự cố lớn nổ ra vào thứ ba và mọi thứ khác trở nên thứ yếu. Loại sự không thể đoán trước kéo dài này khiến nó gần như không thể xây dựng một văn hóa làm việc sâu sắc – điều mà cuối cùng lại thúc đẩy kết quả kỹ thuật tốt nhất.

Nó cũng tạo ra một chu kỳ tự củng cố. Đầu tư bị hoãn lại có nghĩa là nhiều sự cố hơn, điều này có nghĩa là nhiều chữa cháy hơn, điều này có nghĩa là ít thời gian hơn để đầu tư vào các vấn đề cơ bản. Tại Strudel, một phần lớn của những gì chúng tôi đang xây dựng là dành riêng cho các đội SRE đang sống mỗi ngày.

Strudel kết nối dữ liệu hỗ trợ khách hàng, nhật ký, hệ thống sản xuất và kho mã để xác định nguyên nhân gốc rễ nhanh hơn. Trí tuệ nhân tạo kết hợp các tín hiệu kỹ thuật khác nhau này như thế nào để các công cụ giám sát truyền thống không thể?

Các công cụ giám sát truyền thống cơ bản là các hệ thống cảnh báo. Chúng tuyệt vời trong việc thông báo cho bạn biết điều gì đó đã vượt qua ngưỡng – một sự tăng vọt độ trễ, một tỷ lệ lỗi tăng, một pod bị sập. Điều chúng không thể làm là lý luận qua các miền.

Chúng không biết rằng sự tăng vọt tỷ lệ lỗi trong dịch vụ thanh toán của bạn xảy ra bốn phút sau khi triển khai một phụ thuộc, và rằng một vé hỗ trợ khách hàng đề cập đến sự cố thanh toán đã đến vào khoảng thời gian đó, và rằng lần cuối cùng mẫu này xuất hiện trong nhật ký của bạn là sáu tháng trước trong một cuộc di chuyển cơ sở dữ liệu.

Loại tương quan giữa các miền này là những gì trí tuệ nhân tạo cho phép. Chúng tôi có thể coi một vé Zendesk, một cam kết GitHub, một dấu vết Datadog (DDOG ) và một nhật ký CloudWatch như một phần của một câu chuyện thống nhất chứ không phải là các điểm dữ liệu riêng biệt. Trí tuệ nhân tạo đưa ra không chỉ những gì bị hỏng, mà còn là tại sao và ở đâu có thể – và nó dựa trên bằng chứng mà một kỹ sư con người thực sự có thể xác minh và hành động. Chúng tôi không yêu cầu các đội tin tưởng vào một hộp đen. Chúng tôi đang đưa cho họ một giả thuyết được lý luận tốt và một bước chạy đầu.

Bạn mô tả Strudel như một nền tảng cung cấp “trí tuệ kỹ thuật”. Khái niệm này có nghĩa là gì trong thực tế, và nó khác với các nền tảng quan sát hoặc AIOps truyền thống như thế nào?

Kristin: Khả năng quan sát cơ bản là về công cụ và khả năng hiển thị – đảm bảo rằng telemetry có mặt và các đội có thể truy vấn nó. AIOps, trong hầu hết các triển khai hiện tại, là về việc giảm tiếng ồn cảnh báo thông qua sự tương quan và phát hiện bất thường dựa trên ML. Cả hai đều có giá trị thực sự, và chúng tôi tích hợp với chúng.

Tuy nhiên, trí tuệ kỹ thuật là một lớp trên. Chúng tôi đang thực hiện những gì AIOps làm và mở rộng trên nó. Trong khi AIOps cho bạn biết điều gì đó sai, trí tuệ kỹ thuật giúp bạn hiểu tại sao nó sai, từ đâu bắt đầu và làm thế nào để giải quyết nó – bằng cách kéo tín hiệu từ toàn bộ ngăn xếp của bạn, bao gồm cả nguồn mà các công cụ AIOps truyền thống thậm chí không xem xét, như vé hỗ trợ khách hàng hoặc thay đổi mã. Mục tiêu không chỉ là giảm tiếng ồn. Đó là đưa cho đội của bạn một hình ảnh hoàn chỉnh, có thể hành động để họ có thể giải quyết vấn đề nhanh hơn và quay lại xây dựng.

Cứ nghĩ về nó như sự khác biệt giữa một thiết bị báo khói và một điều tra viên hỏa hoạn. Khả năng quan sát và AIOps là thiết bị báo khói – thiết yếu, nhưng chúng dừng lại ở cảnh báo. Trí tuệ kỹ thuật là những gì đến sau: đó là những gì đã xảy ra, tại sao, và từ đâu bắt đầu.

Các tác nhân trí tuệ nhân tạo đang ngày càng được triển khai để tự động hóa các công việc kỹ thuật phức tạp. Bạn thấy các tác nhân trí tuệ nhân tạo sẽ đóng vai trò gì trong việc chẩn đoán và giải quyết các sự cố phần mềm trong năm năm tới?

Tôi nghĩ câu hỏi thú vị hơn không phải là những gì các tác nhân sẽ làm – mà là những gì kỹ sư sẽ ngừng làm. Các kỹ sư giỏi nhất mà tôi đã làm việc cùng không vào lĩnh vực này để dành đêm của họ để phân tích cảnh báo hoặc tìm kiếm qua nhật ký để tìm một thay đổi cấu hình mà ai đó đã thực hiện vào một chiều thứ sáu. Đó không phải là lý do họ trở nên giỏi trong công việc của mình. Nhưng đó là những gì một lượng lớn thời gian của họ bị chiếm dụng.

Trong năm năm tới, tôi nghĩ các tác nhân sẽ thực hiện rất nhiều công việc nhàm chán – công việc đối sánh mẫu, xây dựng ngữ cảnh, công việc quan trọng nhưng không phải là nơi tài năng kỹ sư cấp cao nên dành thời gian của họ. Điều đó giải phóng mọi người tập trung vào các vấn đề phức tạp, các quyết định kiến trúc, những thứ thực sự đòi hỏi phán đoán của con người.

Cái thú vị đối với tôi là điều này không chỉ là một trạng thái tương lai – chúng tôi đang thấy nó diễn ra ngay bây giờ, bao gồm cả tại Strudel. Toàn bộ đường lối của chúng tôi được định hướng để loại bỏ công việc hành chính và bảo trì khỏi bảng của các kỹ sư. Và những gì chúng tôi đang tìm thấy,onestly, là nó thay đổi những gì có thể cho một đội. Bạn có thể xây dựng nhiều hơn, di chuyển nhanh hơn và làm điều đó với ít người hơn – vì những người bạn có đang tập trung vào chiến lược và sự phức tạp chứ không phải là việc trả nợ cho công việc lặp đi lặp lại. Điều đó cảm thấy như một sự thay đổi có ý nghĩa trong cách các đội được xây dựng và cấu trúc trong tương lai.

Nhiều thời gian ngừng hoạt động bắt nguồn từ các lỗi nhỏ hoặc thay đổi cấu hình trượt qua thử nghiệm. Làm thế nào các hệ thống trí tuệ nhân tạo có thể xác định các mẫu tinh vi trong mã, nhật ký hoặc tín hiệu cơ sở hạ tầng đủ sớm để ngăn chặn các sự cố lớn?

Trí tuệ nhân tạo được thiết kế tốt có một lợi thế thực sự ở đây, và nó không phải là vì nó thông minh hơn các kỹ sư của bạn – mà là vì nó không bao giờ quên và không bao giờ ngủ. Một con người có thể không kết nối một mẫu nhật ký tinh vi ngày hôm nay với điều gì đó đã xảy ra sáu tháng trước trong một phần khác của hệ thống. Trí tuệ nhân tạo có thể. Nó đang theo dõi tất cả, mọi lúc, và nó có một trí nhớ dài hơn và rộng hơn nhiều so với bất kỳ cá nhân nào trong đội của bạn.

Được nói, cũng có một điều khác mà chúng tôi nghe từ khách hàng rất nhiều: phòng ngừa chỉ tốt như dữ liệu bên dưới nó. Nếu nhật ký của bạn không nhất quán, không đầy đủ hoặc bị phân mảnh trên một tá công cụ không nói chuyện với nhau, thì trí tuệ nhân tạo đang làm việc với một bức tranh bị phân mảnh. Rác vào, rác ra – điều đó vẫn đúng. Chúng tôi dành rất nhiều thời gian với khách hàng giúp họ suy nghĩ về chất lượng dữ liệu và công cụ vì hệ thống trí tuệ nhân tạo tốt nhất trên thế giới không thể đưa ra một tín hiệu mà không bao giờ được thu thập từ đầu.

Do đó, câu trả lời là cả hai: có, trí tuệ nhân tạo có thể bắt những điều đó sớm hơn và kết nối các điểm mà con người sẽ bỏ lỡ. Nhưng các đội nhận được giá trị nhất từ nó là những đội đã làm việc để đảm bảo dữ liệu của họ thực sự đáng được suy luận.

Các công ty thường đầu tư nhiều vào các công cụ phát hiện nhưng vẫn gặp khó khăn với thời gian giải quyết trung bình. Những rào cản lớn nhất ngăn cản các tổ chức đóng khoảng cách giữa phát hiện sự cố và giải quyết nguyên nhân gốc rễ là gì?

Phát hiện cơ bản là một vấn đề đã được giải quyết tại thời điểm này. Hầu hết các đội đều có cảnh báo. Họ biết điều gì đó sai. Khoảng cách là mọi thứ xảy ra tiếp theo.

Khi một kỹ sư được gọi, họ không bước vào một tình huống rõ ràng với tất cả ngữ cảnh liên quan được thu thập gọn gàng. Họ bước vào một mớ hỗn độn. Họ phải tìm ra những gì đã thay đổi, khi nào nó thay đổi, hệ thống nào nó chạm vào, liệu có tác động đến khách hàng hay không, liệu nó có liên quan đến điều gì đó đã xảy ra tuần trước. Họ đang kéo từ Slack, từ bảng điều khiển, từ nhật ký triển khai, từ vé hỗ trợ – làm việc lắp ráp ngữ cảnh thủ công, dưới áp lực, thường vào giữa đêm.

Công việc lắp ráp ngữ cảnh là nút thắt cổ chai. Không phải kỹ sư và đội hỗ trợ không biết cách giải quyết vấn đề – mà là họ đang dành 30 đến 60 phút đầu tiên của mỗi sự cố chỉ để cố hiểu họ đang nhìn gì. Đó là nơi Strudel sống. Toàn bộ luận điểm của chúng tôi là nếu bạn có thể đưa cho một kỹ sư một bức tranh mạch lạc, có bằng chứng về những gì đã xảy ra và tại sao – ngay khi họ cần – bạn sẽ nén đáng kể khoảng cách đó. Công việc giải quyết vẫn thuộc về họ. Chúng tôi chỉ đưa họ đến vạch xuất phát nhanh hơn.

Khi các hệ thống trí tuệ nhân tạo bắt đầu phân tích dữ liệu sản xuất, mã nguồn và nhật ký hoạt động, những cân nhắc về quản trị hoặc bảo mật nào mà các đội kỹ thuật nên lưu ý khi triển khai các công cụ này?

Điều tôi cảm thấy mạnh mẽ nhất ở đây là: con người vẫn nên xem xét mã được đưa vào sản xuất.

Tôi đã nói chuyện với nhiều kỹ sư về điều này, và một điều tôi nghe thấy nhiều lần là: trí tuệ nhân tạo viết lỗi một cách hiệu quả và thông minh. Thực sự thông minh, thực sự. Theo cách mà có thể rất khó bắt – ngay cả đối với các kỹ sư cấp cao đang xem xét mã cẩn thận. Các lỗi không phải lúc nào cũng rõ ràng. Chúng có thể trông hoàn hảo khi xem xét thoáng qua.

Do đó, tôi nghĩ chúng tôi sẽ thấy nhiều vấn đề tinh vi, khó phát hiện này trượt qua – không phải vì bất kỳ ai đã cẩu thả, mà vì bản chất của các lỗi do trí tuệ nhân tạo tạo ra là khác. Khó phát hiện trong xem xét. Khó bắt trong thử nghiệm.

Thành thực? Đó là một trong những lý do tôi nghĩ trường hợp cho những gì Strudel làm chỉ trở nên mạnh mẽ hơn theo thời gian. Nếu nhiều lỗi hơn đang làm cho nó vào sản xuất, khả năng tìm và giải quyết chúng nhanh hơn trở nên quan trọng hơn, không kém. Câu hỏi quản trị không chỉ là về kiểm soát truy cập dữ liệu và quyền – mặc dù những điều đó quan trọng và các đội nên suy nghĩ cẩn thận về những gì dữ liệu họ đang đưa cho bất kỳ hệ thống trí tuệ nhân tạo nào. Đó cũng là về việc giữ con người ở những điểm kiểm tra phù hợp, đặc biệt là xung quanh bất cứ điều gì chạm vào sản xuất.

Nhìn về tương lai, bạn có nghĩ rằng tương lai của kỹ thuật độ tin cậy sẽ chuyển hướng sang cơ sở hạ tầng “trí tuệ nhân tạo đầu tiên”, nơi các hệ thống tự động giám sát, chẩn đoán và thậm chí sửa lỗi trước khi con người nhận thức được sự cố?

Tôi nghĩ chúng tôi đang đi theo hướng đó, nhưng tôi thực tế về đường thời gian. Các hệ thống tự động hoàn toàn giải quyết các sự cố sản xuất mà không có sự nhận thức của con người – đó không phải là nơi chúng tôi đang ở, và tôi không nghĩ đó là nơi chúng tôi sẽ ở trong vài năm tới. Và tôi nghĩ đó ổn.

Cái tôi tin là vòng lặp sẽ trở nên chặt chẽ và ít đau đớn hơn. Tương lai tôi hào hứng không phải là một nơi con người bị loại bỏ khỏi phương trình – mà là nơi con người tích hợp vào quá trình dành thời gian cho những phần thực sự đòi hỏi họ. Các quyết định phán đoán. Các tình huống mới. Một sự cố bạn chưa từng thấy trước đây. Trí tuệ nhân tạo xử lý việc đối sánh mẫu, lắp ráp ngữ cảnh, phân tích thường xuyên. Kỹ sư xử lý các quyết định.

Đối với các kỹ sư, tôi nghĩ nó trông như: ít thời gian trên gọi vào giữa đêm cho những thứ không cần phải đánh thức họ, và nhiều thời gian hơn để xây dựng các hệ thống không bị hỏng ngay từ đầu. Việc chữa cháy không biến mất hoàn toàn. Nhưng nó trở thành ngoại lệ chứ không phải là trạng thái mặc định của việc là một kỹ sư tại một công ty chạy phần mềm với quy mô lớn. Đó là một tương lai đáng xây dựng.

Cảm ơn vì cuộc phỏng vấn tuyệt vời, độc giả muốn tìm hiểu thêm nên truy cập Strudel.