Chúc mọi người thứ sáu vui vẻ! Các bạn ơi, hôm nay chúng ta tiếp tục chuỗi ấn phẩm dành riêng cho khóa học , vì các lớp trong nhóm mới của khóa học sẽ bắt đầu vào cuối tuần sau. Vì vậy, hãy bắt đầu!
Giám sát là chỉ. Đây là một thực tế được biết. Mở Nagios, chạy NRPE trên hệ thống từ xa, định cấu hình Nagios trên cổng NRPE TCP 5666 và bạn có quyền giám sát.
Dễ dàng đến mức không thú vị. Bây giờ bạn có các số liệu cơ bản về thời gian CPU, hệ thống con đĩa, RAM, được cung cấp theo mặc định cho Nagios và NRPE. Nhưng thực tế đây không phải là “giám sát” như vậy. Điều này chỉ là khởi đầu.
(Thông thường, họ cài đặt PNP4Nagios, RRDtool và Thruk, thiết lập thông báo trong Slack và truy cập thẳng vào nagiosexchange, nhưng bây giờ chúng ta hãy bỏ qua điều đó).
Giám sát tốt thực sự khá phức tạp, bạn thực sự cần biết nội bộ của ứng dụng bạn đang theo dõi.
Giám sát có khó không?
Bất kỳ máy chủ nào, dù là Linux hay Windows, theo định nghĩa đều sẽ phục vụ một số mục đích. Apache, Samba, Tomcat, lưu trữ tệp, LDAP - tất cả các dịch vụ này ít nhiều độc đáo ở một hoặc nhiều khía cạnh. Mỗi cái đều có chức năng riêng, đặc điểm riêng. Có nhiều cách khác nhau để lấy số liệu, KPI (các chỉ số hiệu suất chính), mà bạn thấy thú vị khi máy chủ đang tải.
Tác giả của bức ảnh trên
(Ước gì bảng điều khiển của tôi có màu xanh neon - thở dài mơ màng -... hmm...)
Bất kỳ phần mềm nào cung cấp dịch vụ đều phải có cơ chế thu thập số liệu. Apache có một mô-đun mod-status, hiển thị trang trạng thái máy chủ. Nginx có - stub_status. Tomcat có JMX hoặc các ứng dụng web tùy chỉnh hiển thị các số liệu chính. MySQL có lệnh "hiển thị trạng thái toàn cầu", v.v.
Vậy tại sao các nhà phát triển không xây dựng những cơ chế tương tự vào ứng dụng mà họ tạo ra?
Có phải chỉ các nhà phát triển mới làm điều này?
Mức độ thờ ơ nhất định đối với việc nhúng số liệu không chỉ giới hạn ở các nhà phát triển. Tôi đã làm việc tại các công ty nơi họ phát triển ứng dụng bằng Tomcat và không cung cấp bất kỳ số liệu nào của riêng họ, không có nhật ký hoạt động dịch vụ, ngoại trừ nhật ký lỗi chung của Tomcat. Một số nhà phát triển tạo ra rất nhiều nhật ký chẳng có ý nghĩa gì đối với quản trị viên hệ thống, những người không may mắn đọc được chúng vào lúc 3:15 sáng.
Tác giả của bức ảnh trên
Các kỹ sư hệ thống cho phép phát hành các sản phẩm đó cũng phải chịu một số trách nhiệm về tình huống này. Rất ít kỹ sư hệ thống có thời gian hoặc quan tâm đến việc cố gắng trích xuất các số liệu có ý nghĩa từ nhật ký mà không có ngữ cảnh của các số liệu đó và khả năng diễn giải chúng theo hoạt động của ứng dụng. Một số không hiểu làm thế nào họ có thể hưởng lợi từ nó, ngoài các chỉ báo "hiện tại (hoặc sẽ sớm) sai".
Sự thay đổi trong suy nghĩ về nhu cầu về số liệu phải xảy ra không chỉ giữa các nhà phát triển mà còn giữa các kỹ sư hệ thống.
Đối với bất kỳ kỹ sư hệ thống nào không chỉ cần ứng phó với các sự kiện quan trọng mà còn cần đảm bảo rằng chúng không xảy ra, việc thiếu số liệu thường là rào cản để thực hiện điều đó.
Tuy nhiên, các kỹ sư hệ thống thường không mày mò mã để kiếm tiền cho công ty của họ. Họ cần những nhà phát triển chính hiểu được tầm quan trọng của trách nhiệm của kỹ sư hệ thống trong việc xác định các vấn đề, nâng cao nhận thức về các vấn đề hiệu suất và những thứ tương tự.
Điều này dành cho người sùng đạo
Tâm lý devops mô tả sức mạnh tổng hợp giữa tư duy phát triển (dev) và vận hành (ops). Bất kỳ công ty nào tuyên bố "làm devops" đều phải:
- nói những điều mà có lẽ họ không làm (đề cập đến meme Cô dâu công chúa - "Tôi không nghĩ nó có nghĩa như bạn nghĩ!")
- Khuyến khích thái độ cải tiến sản phẩm liên tục.
Bạn không thể cải tiến một sản phẩm và biết rằng nó đã được cải tiến nếu bạn không biết nó hiện đang hoạt động như thế nào. Bạn không thể biết một sản phẩm hoạt động như thế nào nếu bạn không hiểu các thành phần của nó hoạt động như thế nào, các dịch vụ mà sản phẩm đó phụ thuộc, những điểm yếu và điểm nghẽn chính của sản phẩm đó.
Nếu bạn không chú ý đến những tắc nghẽn tiềm ẩn, bạn sẽ không thể tuân theo kỹ thuật Five Whys khi viết Postmortem. Bạn sẽ không thể đặt mọi thứ lên một màn hình để xem sản phẩm hoạt động như thế nào hoặc biết nó trông “bình thường và hạnh phúc” như thế nào.
Dịch sang trái, TRÁI, TÔI NÓI LEEEE—
Đối với tôi, một trong những nguyên tắc chính của Devops là “chuyển sang trái”. Dịch chuyển sang trái trong ngữ cảnh này có nghĩa là dịch chuyển khả năng (không có trách nhiệm, nhưng chỉ có khả năng) để thực hiện những việc mà các kỹ sư hệ thống thường quan tâm, chẳng hạn như tạo số liệu hiệu suất, sử dụng nhật ký hiệu quả hơn, v.v., ở bên trái trong Vòng đời Phân phối Phần mềm.
Tác giả của bức ảnh trên
Các nhà phát triển phần mềm phải có khả năng sử dụng và biết các công cụ giám sát mà công ty sử dụng để thực hiện giám sát dưới mọi hình thức, số liệu, ghi nhật ký, giao diện giám sát và quan trọng nhất là xem sản phẩm của họ hoạt động như thế nào trong quá trình sản xuất. Bạn không thể yêu cầu các nhà phát triển đầu tư công sức và thời gian vào việc giám sát cho đến khi họ có thể xem các số liệu và ảnh hưởng đến giao diện của chúng, cách chủ sở hữu sản phẩm trình bày chúng với CTO trong cuộc họp giao ban tiếp theo, v.v.
Nói ngắn gọn
- Dẫn ngựa của bạn xuống nước. Cho các nhà phát triển thấy họ có thể tránh được bao nhiêu rắc rối cho bản thân, giúp họ xác định KPI và số liệu phù hợp cho ứng dụng của mình để chủ sở hữu sản phẩm ít bị CTO la mắng hơn. Hãy đưa họ ra ánh sáng một cách nhẹ nhàng và bình tĩnh. Nếu cách đó không hiệu quả, thì hãy hối lộ, đe dọa và dụ dỗ họ hoặc chủ sở hữu sản phẩm để triển khai việc lấy các số liệu này từ ứng dụng càng nhanh càng tốt, sau đó vẽ sơ đồ. Điều này sẽ khó khăn vì nó sẽ không được coi là ưu tiên và lộ trình sản phẩm sẽ có nhiều dự án tạo doanh thu đang chờ xử lý. Do đó, bạn sẽ cần một trường hợp kinh doanh để chứng minh thời gian và chi phí dành cho việc triển khai giám sát sản phẩm.
- Giúp các kỹ sư hệ thống có được giấc ngủ ngon. Cho họ thấy rằng việc sử dụng danh sách kiểm tra “hãy phát hành” cho bất kỳ sản phẩm nào được phát hành là một điều tốt. Và việc đảm bảo tất cả các ứng dụng trong quá trình sản xuất đều được bao phủ bởi các số liệu sẽ giúp bạn ngủ ngon hơn vào ban đêm bằng cách cho phép các nhà phát triển xem điều gì đang xảy ra và ở đâu. Tuy nhiên, cách đúng đắn để chọc tức và làm nản lòng bất kỳ nhà phát triển, chủ sở hữu sản phẩm hoặc CTO nào là kiên trì và phản kháng. Hành vi này sẽ ảnh hưởng đến ngày phát hành của bất kỳ sản phẩm nào nếu bạn lại đợi đến phút cuối cùng, vì vậy hãy chuyển sang trái một lần nữa và đưa những vấn đề này vào kế hoạch dự án của bạn càng sớm càng tốt. Nếu cần, hãy đến các cuộc họp về sản phẩm. Đeo ria mép giả và nỉ hay gì đó, sẽ không bao giờ lỗi mốt. Truyền đạt mối quan tâm của bạn, chứng minh lợi ích rõ ràng và truyền giáo.
- Đảm bảo rằng cả bộ phận phát triển (dev) và vận hành (ops) đều hiểu ý nghĩa và hậu quả của việc các chỉ số sản phẩm chuyển sang vùng màu đỏ. Đừng để Ops là người giám hộ duy nhất về tình trạng sản phẩm, hãy đảm bảo rằng các nhà phát triển cũng tham gia (#productsquads).
- Nhật ký là một thứ tuyệt vời, nhưng các số liệu cũng vậy. Hãy kết hợp chúng lại và đừng để những khúc gỗ của bạn trở thành rác rưởi trong một quả cầu lửa khổng lồ vô dụng. Giải thích và cho các nhà phát triển thấy lý do tại sao không ai khác hiểu nhật ký của họ, cho họ thấy cảm giác nhìn vào nhật ký vô dụng lúc 3:15 sáng.
Tác giả của bức ảnh trên
Đó là tất cả. Tài liệu mới sẽ được phát hành vào tuần tới. Nếu bạn muốn tìm hiểu thêm về khóa học, chúng tôi mời bạn , sẽ diễn ra vào thứ Hai. Và bây giờ chúng tôi đang chờ đợi ý kiến của bạn theo truyền thống.
Nguồn: www.habr.com