Charity Majors, CTO & Co-Founder tại Honeycomb – Loạt Phỏng Vấn

Charity là một kỹ sư vận hành và người sáng lập startup không cố ý tại Honeycomb. Trước đó, cô đã làm việc tại Parse, Facebook (META ) và Linden Lab về cơ sở hạ tầng và công cụ phát triển, và luôn có xu hướng chạy các cơ sở dữ liệu. Cô là đồng tác giả của Database Reliability Engineering của O’Reilly, và yêu thích tự do ngôn luận, phần mềm tự do và rượu whisky đơn malt.

Bạn đã từng là Quản lý Kỹ sư Sản xuất tại Facebook (nay là Meta) trong hơn 2 năm, vậy những điểm nổi bật từ thời kỳ đó và những bài học quan trọng từ kinh nghiệm này là gì?

Tôi đã làm việc trên Parse, một nền tảng cho các ứng dụng di động, giống như Heroku cho di động. Tôi chưa bao giờ quan tâm đến việc làm việc tại một công ty lớn, nhưng chúng tôi đã được Facebook mua lại. Một trong những bài học quan trọng của tôi là việc mua lại thực sự rất khó, ngay cả trong những hoàn cảnh tốt nhất. Lời khuyên tôi luôn đưa ra cho các nhà sáng lập khác bây giờ là: nếu bạn sẽ được mua lại, hãy đảm bảo bạn có một nhà tài trợ điều hành và suy nghĩ thật kỹ về việc bạn có sự phù hợp chiến lược hay không. Facebook đã mua lại Instagram không lâu trước khi mua lại Parse, và việc mua lại Instagram đã không dễ dàng, nhưng cuối cùng đã rất thành công vì họ đã có sự phù hợp chiến lược và một nhà tài trợ mạnh mẽ.

Tôi đã không có một thời gian dễ dàng tại Facebook, nhưng tôi rất biết ơn về thời gian tôi đã dành tại đó; tôi không biết liệu tôi có thể bắt đầu một công ty nếu không có những bài học tôi đã học về cấu trúc tổ chức, quản lý, chiến lược, v.v. Điều đó cũng cho tôi một danh tiếng mà làm cho tôi trở nên hấp dẫn với các nhà đầu tư mạo hiểm, không ai trong số họ đã dành cho tôi thời gian cho đến thời điểm đó. Tôi有点 khó chịu về điều này, nhưng tôi vẫn sẽ chấp nhận nó.

Bạn có thể chia sẻ câu chuyện về việc ra mắt Honeycomb?

Tất nhiên. Từ góc độ kiến trúc, Parse đã đi trước thời đại – chúng tôi đã sử dụng các dịch vụ vi mô trước khi có các dịch vụ vi mô, chúng tôi đã có một lớp dữ liệu phân mảnh lớn và với tư cách là một nền tảng phục vụ hơn một triệu ứng dụng di động, chúng tôi đã có rất nhiều vấn đề đa thuê bao phức tạp. Khách hàng của chúng tôi là các nhà phát triển, và họ luôn viết và tải lên các đoạn mã và truy vấn mới với chất lượng “khác nhau” – và chúng tôi chỉ cần phải chấp nhận tất cả và làm cho nó hoạt động, bằng cách nào đó.

Chúng tôi đã đi đầu trong một loạt các thay đổi đã trở thành phổ biến. Trước đây, hầu hết các kiến trúc đều khá đơn giản và sẽ thất bại một cách lặp đi lặp lại theo những cách có thể dự đoán được. Bạn thường có một lớp web, một ứng dụng và một cơ sở dữ liệu, và hầu hết sự phức tạp đều bị ràng buộc trong mã ứng dụng của bạn. Vì vậy, bạn sẽ viết các kiểm tra giám sát để theo dõi những sự thất bại này và xây dựng các bảng điều khiển tĩnh cho dữ liệu giám sát và đo lường của bạn.

Ngành công nghiệp này đã chứng kiến sự bùng nổ về sự phức tạp kiến trúc trong 10 năm qua. Chúng tôi đã phá vỡ kiến trúc monolithic, vì vậy bây giờ bạn có từ vài dịch vụ đến hàng nghìn dịch vụ ứng dụng vi mô. Sự tồn tại đa ngôn ngữ là bình thường; thay vì “cơ sở dữ liệu”, điều bình thường là có nhiều loại lưu trữ khác nhau cũng như phân mảnh ngang, lớp缓存, cơ sở dữ liệu cho mỗi dịch vụ vi mô, hàng đợi và nhiều hơn nữa. Trên hết, bạn có các container được lưu trữ trên máy chủ, dịch vụ và nền tảng của bên thứ ba, mã không có máy chủ, lưu trữ khối và nhiều hơn nữa.

Phần khó trước đây là gỡ lỗi mã của bạn; bây giờ, phần khó là tìm ra nơi trong hệ thống mà mã bạn cần gỡ lỗi. Thay vì thất bại một cách lặp đi lặp lại theo những cách có thể dự đoán được, điều đó có nhiều khả năng xảy ra là mỗi lần bạn nhận được cuộc gọi, đó là về một điều gì đó bạn chưa từng thấy trước đây và có thể sẽ không bao giờ thấy lại.

Gỡ lỗi những vấn đề này từ đầu là vô cùng khó. Với nhật ký và đo lường, bạn cơ bản phải biết bạn đang tìm kiếm gì trước khi bạn có thể tìm thấy nó. Nhưng chúng tôi đã bắt đầu cho một số tập dữ liệu vào một công cụ của Facebook gọi là Scuba, cho phép chúng tôi cắt và cắt theo các chiều không gian tùy ý và dữ liệu có tính chất cao trong thời gian thực, và thời gian nó mất để chúng tôi xác định và giải quyết những vấn đề này từ đầu đã giảm như một hòn đá, từ vài giờ đến … vài phút? vài giây? Đó không còn là một vấn đề kỹ thuật nữa, đó là một vấn đề hỗ trợ. Bạn có thể chỉ cần theo dõi dấu vết của các mảnh vụn đến câu trả lời mỗi lần, nhấp chuột.

Điều đó thật tuyệt vời. Một nguồn không chắc chắn và lao động và khách hàng không hài lòng và các trang 2 giờ sáng chỉ … biến mất. Cho đến khi Christine và tôi rời Facebook, chúng tôi mới nhận ra rằng nó đã biến đổi cách chúng tôi tương tác với phần mềm như thế nào. Việc quay lại những ngày cũ của việc giám sát và bảng điều khiển là không thể tưởng tượng được.

Nhưng vào thời điểm đó, chúng tôi thực sự nghĩ rằng đây sẽ là một giải pháp đặc biệt – nó giải quyết một vấn đề mà các nền tảng đa thuê bao lớn khác có thể có. Cho đến khi chúng tôi đã xây dựng được gần một năm, chúng tôi mới bắt đầu nhận ra rằng, ôi trời, điều này thực sự đang trở thành một vấn đề của mọi người.

Đối với những người đọc chưa quen, cụ thể observability platform là gì và nó khác với giám sát truyền thống và đo lường như thế nào?

Giám sát truyền thống nổi tiếng có ba trụ cột: đo lường, nhật ký và dấu vết. Bạn thường cần mua nhiều công cụ để đáp ứng nhu cầu của mình: nhật ký, dấu vết, APM, RUM, bảng điều khiển, trực quan hóa, v.v. Mỗi công cụ này được tối ưu hóa cho một trường hợp sử dụng khác nhau trong một định dạng khác nhau. Với tư cách là một kỹ sư, bạn ngồi ở giữa những công cụ này, cố gắng hiểu tất cả chúng. Bạn lướt qua các bảng điều khiển để tìm kiếm các mẫu trực quan, bạn sao chép và dán các ID từ nhật ký sang dấu vết và ngược lại. Điều đó rất phản ứng và từng phần, và thường bạn tham khảo những công cụ này khi bạn có một vấn đề – chúng được thiết kế để giúp bạn vận hành mã của bạn và tìm lỗi và lỗi.

Khả năng quan sát hiện đại có một nguồn sự thật duy nhất; các sự kiện nhật ký cấu trúc tùy ý rộng. Từ những sự kiện này, bạn có thể suy ra các đo lường, bảng điều khiển và nhật ký của mình. Bạn có thể trực quan hóa chúng theo thời gian như một dấu vết, bạn có thể cắt và cắt, bạn có thể thu phóng vào các yêu cầu riêng lẻ và ra ngoài để xem tổng thể. Bởi vì mọi thứ đều được kết nối, bạn không cần phải nhảy từ công cụ này sang công cụ khác, đoán hoặc dựa vào trực giác. Khả năng quan sát hiện đại không chỉ về cách bạn vận hành hệ thống của mình, mà còn về cách bạn phát triển mã của mình. Đó là lớp nền tảng cho phép bạn kết nối các vòng phản hồi mạnh mẽ và chặt chẽ giúp bạn giao hàng nhiều giá trị cho người dùng một cách nhanh chóng, với sự tự tin, và tìm ra các vấn đề trước khi người dùng của bạn làm như vậy.

Bạn được biết đến với việc tin rằng khả năng quan sát cung cấp một nguồn sự thật duy nhất trong môi trường kỹ sư. Làm thế nào AI tích hợp vào tầm nhìn này, và những lợi ích và thách thức của nó trong bối cảnh này là gì?

Khả năng quan sát giống như đeo kính trước khi bạn lao xuống đường cao tốc. Phát triển theo định hướng thử nghiệm (TDD) đã cách mạng hóa phần mềm vào đầu những năm 2000, nhưng TDD đã mất hiệu quả khi sự phức tạp nằm trong hệ thống của chúng tôi thay vì chỉ trong phần mềm của chúng tôi. Ngày càng nhiều, nếu bạn muốn có được những lợi ích liên quan đến TDD, bạn thực sự cần phải lập công cụ mã của bạn và thực hiện một thứ gì đó tương tự như khả năng quan sát được thúc đẩy bởi phát triển, hoặc ODD, nơi bạn lập công cụ khi bạn đi, triển khai nhanh, sau đó nhìn vào mã của bạn trong sản xuất thông qua ống kính của công cụ bạn vừa viết và hỏi mình: “liệu nó có làm việc như tôi mong đợi nó làm, và có điều gì khác nhìn … kỳ lạ không?”

Các thử nghiệm đơn độc không đủ để xác nhận rằng mã của bạn đang làm việc như nó được cho là để làm. Bạn không biết điều đó cho đến khi bạn đã xem nó trong sản xuất, với người dùng thực trên cơ sở hạ tầng thực.

Loại phát triển này – bao gồm sản xuất trong các vòng phản hồi nhanh – thực sự nhanh hơn, dễ dàng hơn và đơn giản hơn so với việc dựa vào các thử nghiệm và chu kỳ triển khai chậm hơn. Một khi các nhà phát triển đã thử cách làm việc đó, họ nổi tiếng là không muốn quay lại cách làm việc cũ.

Điều gì khiến tôi hào hứng về AI là khi bạn phát triển với các mô hình ngôn ngữ lớn, bạn phải phát triển trong sản xuất. Cách duy nhất bạn có thể suy ra một tập hợp các thử nghiệm là bằng cách đầu tiên xác thực mã của bạn trong sản xuất và làm việc ngược lại. Tôi nghĩ rằng việc viết phần mềm được hỗ trợ bởi các mô hình ngôn ngữ lớn sẽ trở thành một kỹ năng phổ biến như viết phần mềm được hỗ trợ bởi MySQL hoặc Postgres trong vài năm, và hy vọng của tôi là điều này sẽ kéo các kỹ sư vào một cách sống tốt hơn.

Bạn đã nêu lên những lo ngại về việc tăng nợ kỹ thuật do cuộc cách mạng AI. Bạn có thể giải thích về các loại nợ kỹ thuật mà AI có thể giới thiệu và cách Honeycomb giúp quản lý hoặc giảm thiểu những nợ đó?

Tôi lo lắng về cả nợ kỹ thuật và, có lẽ quan trọng hơn, nợ tổ chức. Một trong những loại nợ kỹ thuật tồi tệ nhất là khi bạn có phần mềm mà không ai hiểu. Điều đó có nghĩa là bất cứ khi nào bạn cần mở rộng hoặc thay đổi mã đó, hoặc gỡ lỗi hoặc sửa chữa nó, ai đó phải làm việc khó khăn để học nó.

Và nếu bạn đưa mã vào sản xuất mà không ai hiểu, có rất nhiều khả năng rằng nó không được viết để có thể hiểu được. Mã tốt được viết để dễ đọc và hiểu và mở rộng. Nó sử dụng các quy ước và mẫu, nó sử dụng đặt tên nhất quán và mô-đun hóa, nó cân bằng giữa DRY và các yếu tố khác. Chất lượng mã không thể tách rời với việc dễ dàng tương tác với nó. Nếu chúng ta chỉ đưa mã vào sản xuất vì nó biên dịch hoặc vượt qua các thử nghiệm, chúng ta đang tạo ra một tảng băng trôi khổng lồ về các vấn đề kỹ thuật trong tương lai cho chính mình.

Nếu bạn đã quyết định giao mã mà không ai hiểu, Honeycomb không thể giúp với điều đó. Nhưng nếu bạn quan tâm đến việc giao mã sạch, có thể lặp lại, phần mềm, công cụ và khả năng quan sát là tuyệt đối cần thiết cho nỗ lực đó. Công cụ là như tài liệu cộng với báo cáo trạng thái thời gian thực. Công cụ là cách duy nhất bạn có thể xác nhận thực sự rằng phần mềm của bạn đang làm việc như bạn mong đợi, và hành xử theo cách người dùng của bạn mong đợi.

Honeycomb sử dụng AI như thế nào để cải thiện hiệu quả và hiệu quả của các đội kỹ sư?

Các kỹ sư của chúng tôi sử dụng AI rất nhiều nội bộ, đặc biệt là CoPilot. Các kỹ sư trẻ hơn của chúng tôi báo cáo sử dụng ChatGPT mỗi ngày để trả lời các câu hỏi và giúp họ hiểu phần mềm họ đang xây dựng. Các kỹ sư cao cấp hơn của chúng tôi nói rằng nó rất tuyệt vời để tạo ra phần mềm mà sẽ rất繁琐 hoặc khó chịu khi viết, như khi bạn có một tệp YAML khổng lồ để điền vào. Nó cũng hữu ích để tạo ra các đoạn mã trong các ngôn ngữ bạn không thường sử dụng, hoặc từ tài liệu API. Ví dụ, bạn có thể tạo ra các ví dụ thực sự tuyệt vời, có thể sử dụng được từ các SDK và API của AWS, vì nó đã được đào tạo trên các kho lưu trữ có sử dụng thực tế của mã đó.

Tuy nhiên, bất cứ khi nào bạn để AI tạo mã cho bạn, bạn phải đi qua từng dòng một để đảm bảo nó đang làm đúng việc, vì nó sẽ tạo ra rác một cách thường xuyên.

Bạn có thể cung cấp các ví dụ về cách các tính năng được hỗ trợ bởi AI như trợ lý truy vấn hoặc tích hợp Slack của bạn cải thiện sự hợp tác của đội?

Đúng vậy. Trợ lý truy vấn của chúng tôi là một ví dụ tuyệt vời. Sử dụng các công cụ xây dựng truy vấn là phức tạp và khó, ngay cả đối với người dùng mạnh. Nếu bạn có hàng trăm hoặc hàng nghìn chiều trong dữ liệu telemetry của mình, bạn không thể luôn nhớ tên của những chiều có giá trị nhất. Và ngay cả người dùng mạnh cũng quên các chi tiết về cách tạo ra các loại đồ thị nhất định.

Vì vậy, trợ lý truy vấn của chúng tôi cho phép bạn đặt câu hỏi bằng ngôn ngữ tự nhiên. Ví dụ, “điểm cuối chậm nhất là gì?” hoặc “sau khi triển khai lần cuối, điều gì đã xảy ra?” và nó tạo ra một truy vấn và thả bạn vào đó. Hầu hết mọi người thấy khó khi tạo một truy vấn mới từ đầu và dễ dàng khi điều chỉnh một truy vấn hiện có, vì vậy nó giúp bạn có một lợi thế.

Honeycomb hứa hẹn sẽ giải quyết các sự cố nhanh hơn. Bạn có thể mô tả cách tích hợp nhật ký, đo lường và dấu vết vào một loại dữ liệu thống nhất giúp giải quyết vấn đề và giải quyết vấn đề nhanh hơn?

Mọi thứ đều được kết nối. Bạn không cần phải đoán. Thay vì nhìn vào việc bảng điều khiển này có hình dạng giống như bảng điều khiển kia, hoặc đoán rằng sự tăng vọt này trong các đo lường của bạn phải giống như sự tăng vọt này trong nhật ký của bạn dựa trên dấu thời gian … thay vào đó, dữ liệu đều được kết nối. Bạn không cần phải đoán, bạn có thể chỉ hỏi.

Dữ liệu được tạo ra giá trị bởi bối cảnh. Thế hệ công cụ trước đây hoạt động bằng cách loại bỏ tất cả bối cảnh tại thời điểm viết; một khi bạn đã loại bỏ bối cảnh, bạn không bao giờ có thể lấy lại được.

Cũng như: với nhật ký và đo lường, bạn phải biết bạn đang tìm kiếm gì trước khi bạn có thể tìm thấy nó. Điều đó không đúng với khả năng quan sát hiện đại. Bạn không cần phải biết bất cứ điều gì, hoặc tìm kiếm bất cứ điều gì.

Khi bạn lưu trữ dữ liệu bối cảnh phong phú này, bạn có thể làm những việc với nó mà cảm thấy như魔法. Chúng tôi có một công cụ gọi là BubbleUp, nơi bạn có thể vẽ một bong bóng xung quanh bất cứ điều gì bạn nghĩ là kỳ lạ hoặc có thể thú vị, và chúng tôi tính toán tất cả các chiều bên trong bong bóng so với bên ngoài bong bóng, baseline, và sắp xếp và khác biệt chúng. Vì vậy, bạn như “bong bóng này kỳ lạ” và chúng tôi ngay lập tức cho bạn biết, “nó khác nhau theo các cách xyz”. Vậy là rất nhiều việc gỡ lỗi có thể được thu gọn thành “điều này tôi quan tâm đến, nhưng tại sao tôi lại quan tâm đến nó?” Khi bạn có thể ngay lập tức xác định rằng nó khác nhau vì các yêu cầu này đến từ thiết bị Android, với bản xây dựng này, sử dụng gói ngôn ngữ này, trong khu vực này, với ID ứng dụng này, với một payload lớn … bây giờ bạn có thể biết chính xác điều gì sai và tại sao.

Điều đó không chỉ về dữ liệu thống nhất, mà còn về cách chúng tôi xử lý dữ liệu có tính chất cao một cách dễ dàng, như các ID duy nhất, ID giỏ hàng, ID ứng dụng, tên và họ, v.v. Thế hệ công cụ trước đây không thể xử lý dữ liệu phong phú như vậy, điều mà khi bạn nghĩ về nó, là không thể tin được, vì dữ liệu phong phú, có tính chất cao là dữ liệu quý giá và xác định nhất.

Cải thiện khả năng quan sát như thế nào chuyển thành kết quả kinh doanh tốt hơn?

Đây là một trong những thay đổi lớn khác từ thế hệ trước đến thế hệ mới của các công cụ khả năng quan sát. Trong quá khứ, hệ thống, ứng dụng và dữ liệu kinh doanh đều được lưu trữ riêng biệt trong các công cụ khác nhau. Điều này là vô lý – mỗi câu hỏi thú vị bạn muốn hỏi về các hệ thống hiện đại đều có các yếu tố của cả ba.

Khả năng quan sát không chỉ về các lỗi, thời gian ngừng hoạt động hoặc sự cố. Đó là về việc đảm bảo rằng chúng tôi đang làm việc trên những điều đúng đắn, rằng người dùng của chúng tôi đang có một trải nghiệm tuyệt vời, rằng chúng tôi đang đạt được các kết quả kinh doanh mà chúng tôi đang nhắm tới. Đó là về việc xây dựng giá trị, không chỉ vận hành. Nếu bạn không thể nhìn thấy nơi bạn đang đi, bạn sẽ không thể di chuyển nhanh và bạn sẽ không thể điều chỉnh hướng nhanh. Càng có nhiều khả năng quan sát, bạn càng trở thành một kỹ sư tốt hơn và mạnh mẽ hơn.

Bạn nhìn thấy tương lai của khả năng quan sát đang đi tới đâu, đặc biệt là liên quan đến các phát triển AI?

Khả năng quan sát ngày càng nhiều về việc cho phép các đội kết nối các vòng phản hồi nhanh chóng, vì vậy họ có thể phát triển nhanh chóng, với sự tự tin, trong sản xuất, và lãng phí ít thời gian và năng lượng.

Điều đó là về việc kết nối các điểm giữa kết quả kinh doanh và phương pháp kỹ thuật.

Và đó là về việc đảm bảo rằng chúng tôi hiểu phần mềm chúng tôi đang đưa ra thế giới. Khi phần mềm và hệ thống trở nên phức tạp hơn, và đặc biệt là khi AI ngày càng được tích hợp, điều quan trọng hơn bao giờ hết là chúng tôi phải tự ràng buộc mình với một tiêu chuẩn con người về sự hiểu biết và khả năng quản lý.

Từ góc độ khả năng quan sát, chúng tôi sẽ thấy sự tinh vi ngày càng tăng trong đường ống dữ liệu – sử dụng học máy và các kỹ thuật lấy mẫu tinh vi để cân bằng giá trị so với chi phí, để giữ càng nhiều chi tiết càng tốt về các sự kiện ngoại lệ và các sự kiện quan trọng và lưu trữ tóm tắt của phần còn lại với chi phí thấp nhất có thể.

Các nhà cung cấp AI đang đưa ra nhiều tuyên bố quá mức về việc họ có thể hiểu phần mềm của bạn tốt hơn bạn, hoặc họ có thể xử lý dữ liệu và cho người dùng của bạn biết hành động nào để thực hiện. Từ mọi thứ tôi đã thấy, đó là một giấc mơ đắt tiền. Các cảnh báo sai là rất tốn kém. Không có sự thay thế cho việc hiểu hệ thống và dữ liệu của bạn. AI có thể giúp các kỹ sư của bạn với điều đó! Nhưng nó không thể thay thế các kỹ sư của bạn.

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