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 tình cờ tại Honeycomb. Trước đây cô đã làm việc tại Parse, Facebook và Linden Lab về cơ sở hạ tầng và công cụ phát triển, và luôn dường như kết thúc với việc chạy 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 miễn phí và rượu whisky đơn malt.

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

Tôi đã làm việc trên Parse, một nền tảng phía sau cho ứ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 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ự đồng nhất 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 phải là dễ dàng, nhưng cuối cùng nó rất thành công vì họ có sự đồng nhất chiến lược và một nhà tài trợ mạnh mẽ.

Tôi đã không có thời gian dễ dàng tại Facebook, nhưng tôi rất biết ơn thời gian tôi đã dành ở đó; tôi không biết liệu tôi có thể bắt đầu một công ty mà 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. Nó 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 một 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 microservices trước khi có microservices, 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ọ liên tục viết và tải lên các đoạn mã và truy vấn mới của, shall we say, “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 đã ở tiền phong của một loạt thay đổi đã trở thành chủ đạo trong 10 năm qua. Chúng tôi đã phá vỡ kiến trúc monolith, 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 micro. Polyglot persistence là chuẩn mực; thay vì “cơ sở dữ liệu” thông thường, bạn có nhiều loại lưu trữ khác nhau cũng như phân mảnh ngang, lớp caching, cơ sở dữ liệu mỗi microservice, hàng đợi và nhiều hơn nữa. Trên tất cả những điều đó, bạn có container được lưu trữ phía 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 lặp đi lặp lại theo cách có thể dự đoán, nó có nhiều khả năng là mỗi lần bạn nhận được thông báo, nó là về đ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.

Đó là trạng thái chúng tôi ở tại Parse, trên Facebook. Mỗi ngày, toàn bộ nền tảng đều sập, và mỗi lần là điều gì đó khác nhau và mới; một ứng dụng khác đạt vị trí top 10 trên iTunes, một nhà phát triển khác tải lên một truy vấn xấu.

Gỡ lỗi những vấn đề này từ đầu là cực kỳ khó. Với nhật ký và số liệu, 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à chia nhỏ trên 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 cần thiết để 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? Nó không còn là một vấn đề kỹ thuật nữa, nó là một vấn đề hỗ trợ. Bạn chỉ cần theo dõi dấu vết của các dấu vết đến câu trả lời mỗi lần, clicky click click.

Điều đó thật tuyệt vời. Nguồn không chắc chắn và sự khó khăn và khách hàng không hài lòng và thông báo 2 giờ sáng này … chỉ biến mất. Cho đến khi Christine và tôi rời Facebook, chúng tôi mới nhận ra nó đã thay đổi cách chúng tôi tương tác với phần mềm như thế nào. Ý tưởng 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.

Đối với những người đọc chưa quen, bạn có thể chia sẻ câu chuyện về nền tảng quan sát và cách nó khác với giám sát và số liệu truyền thống?

Giám sát truyền thống nổi tiếng có ba trụ cột: số liệu, 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, hình ảnh hóa, v.v. Mỗi công cụ trong số này được tối ưu hóa cho một trường hợp sử dụng khác nhau trong đị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 bảng điều khiển để tìm kiếm các mẫu hình ảnh, bạn sao chép và dán ID từ nhật ký sang dấu vết và ngược lại. Nó 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ã và tìm lỗi của bạn.

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 ý. Từ những sự kiện này, bạn có thể suy ra số liệu, bảng điều khiển và nhật ký của mình. Bạn có thể hình ảnh hóa chúng theo thời gian như một dấu vết, bạn có thể cắt và chia nhỏ, 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. Quan sát hiện đại không chỉ là về cách bạn vận hành hệ thống của mình, nó là về cách bạn phát triển mã của mình. Nó là chất nền 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 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 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ì?

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 đi 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ụ cho mã của mình và thực hiện một số điều tương tự như phát triển quan sát (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: “nó có đang làm những gì tôi mong đợi nó làm không, và có điều gì khác nhìn … kỳ lạ không?”

Các thử nghiệm alone không đủ để xác nhận rằng mã của bạn đang làm những gì 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 – (somewhat counterintuitively) nhanh hơn, dễ dàng hơn và đơn giản hơn so với việc dựa vào thử nghiệm và chu kỳ triển khai chậm hơn. Một khi các nhà phát triển đã thử làm việc theo cách đó, họ nổi tiếng là không muốn quay lại cách làm việc cũ chậm.

Bạn đã nêu lên mối quan ngại về việc gia tăng nợ kỹ thuật do cuộc cách mạng AI. Bạn có thể giải thích 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ợ này không?

Tôi lo lắng về cả nợ kỹ thuật và, có thể 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 rõ. Điều đó có nghĩa là bất cứ khi nào bạn phải mở rộng hoặc thay đổi mã đó, hoặc gỡ lỗi hoặc sửa nó, ai đó phải làm việc khó để học nó.

Và nếu bạn đưa mã vào sản xuất mà không ai hiểu, có khả năng rất cao là nó không được viết để dễ hiểu. Mã tốt được viết để dễ đọc và hiểu và mở rộng. Nó sử dụng 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 cho mọi người tương tác với nó. Nếu chúng tôi chỉ bắt đầu ném mã vào sản xuất vì nó biên dịch hoặc vượt qua thử nghiệm, chúng tôi đang tạo ra một tảng băng kỹ thuật khổng lồ cho các vấn đề tương lai của 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 sẽ và có thể lặp lại, công cụ và quan sát là tuyệt đối cần thiết cho nỗ lực đó. Công cụ giống 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 những gì bạn mong đợi nó làm, và hành xử theo cách người dùng của bạn mong đợi nó hành xử.

Làm thế nào Honeycomb sử dụng AI để 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内部, đặ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â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ó tuyệt vời để tạo ra phần mềm mà sẽ rất tốn thời gian hoặc khó chịu khi viết, như khi bạn có một tệp YAML lớn để điền. Nó cũng hữu ích để tạo ra các đoạn mã trong ngôn ngữ bạn không thường sử dụng, hoặc từ tài liệu API. Giống như, bạn có thể tạo ra một số 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 chứa 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 nó dòng dòng để đảm bảo nó đang làm đúng việc, vì nó sẽ tuyệt đối tạo ra rác rưởi thường xuyên.

Bạn có thể cung cấp 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 tăng cường sự hợp tác của đội?

Tất nhiên. 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 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 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 hỏi câu hỏi bằng ngôn ngữ tự nhiên. Giống như, “những điểm cuối chậm nhất là gì?”, hoặc “điều gì đã xảy ra sau lần triển khai cuối cùng của tôi?” và nó tạo ra một truy vấn và thả bạn vào đó. Hầu hết mọi người đều thấy khó khăn khi tạo một truy vấn mới từ đầu và dễ dàng đ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 giải quyết sự cố nhanh hơn. Bạn có thể mô tả cách tích hợp nhật ký, số liệu 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à gỡ lỗi nhanh hơn không?

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 bảng điều khiển này trông giống như hình dạng của bảng điều khiển khác, hoặc đoán rằng đỉnh này trong số liệu của bạn phải giống như đỉnh 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 có 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: với nhật ký và số liệu, 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 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 ngữ 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ư ma thuật. 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, đường cơ sở, và sắp xếp và khác biệt chúng. Vì vậy, bạn giống 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 biệt theo các cách xyz”. Phần lớn việc gỡ lỗi có thể được giảm xuống thành “đây là điều tôi quan tâm, nhưng tại sao tôi lại quan tâm đến nó?” Khi bạn có thể xác định ngay lập tức rằng nó khác biệt vì những yêu cầu này đến từ thiết bị Android, với ID bản 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 tải trọng lớn … đến thời điểm này, bạn có thể biết chính xác điều gì sai và tại sao.

Nó không chỉ là về dữ liệu thống nhất, mặc dù đó là một phần rất lớn của nó. Nó cũng là 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ư ID duy nhất, ID giỏ hàng, ID ứng dụng, tên đầu tiên / cuối cùng, 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 này thật khó tin khi bạn nghĩ về nó, vì dữ liệu phong phú, có tính chất cao là dữ liệu xác định và có giá trị nhất.

Làm thế nào việc cải thiện quan sát 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 sang thế hệ quan sát mới. 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ề hệ thống hiện đại đều có các yếu tố của cả ba.

Quan sát không chỉ là về lỗi, thời gian ngừng hoạt động hoặc sự cố. Nó 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, 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 kết quả kinh doanh mà chúng tôi đang nhắm tới. Nó 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 không thể điều chỉnh hướng nhanh. Càng có nhiều khả năng nhìn thấy những gì người dùng của bạn đang làm với mã của bạn, bạn sẽ 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 quan sát sẽ đi đâu, đặc biệt là liên quan đến các phát triển AI?

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, để 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.

Nó 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à nó là về việc đảm bảo rằng chúng tôi hiểu phần mề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ó mặt, đ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à quản lý.

Từ quan điểm quan sát, chúng tôi sẽ thấy mức độ 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ữ lại càng nhiều chi tiết càng tốt về các sự kiện ngoài tầm thường 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 về việ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, điều này là một giấc mơ đắt tiền. Các cảnh báo sai là cực kỳ 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, người đọc muốn tìm hiểu thêm nên truy cập Honeycomb.