Khóa học sụp đổ trong Dev cho Ops?

10

Tôi học ở CompSci, nơi chúng tôi chủ yếu được dạy Java, nhưng điều tôi học được ở đây là niềm đam mê của tôi là các hệ thống, vì vậy tôi luôn làm việc theo hướng ops. Tôi thuận tiện với việc viết kịch bản, vì vậy tôi không tìm kiếm một trang web để dạy cho tôi Ruby, nhưng một cái gì đó để giải thích sâu hơn những gì bạn phát triển cả ngày. Tôi muốn hiểu văn hóa tốt hơn và cách bạn tiêu hóa số lượng tệp tuyệt đối trong các dự án của bạn - các tài liệu vô hình.

Nếu tôi biết hôm nay tôi đã được chuyển đến một nhóm phát triển vào thứ Hai, tôi muốn đọc gì vào cuối tuần này?

— Stephen C
nguồn

3

Tôi sẽ bắt đầu đọc "hợp đồng" của mình ... ngay cả khi chỉ cần bạn phân chia lại tiền lương của mình ... Ngoài ra, chỉ cần một ngày cuối tuần là không đủ để đọc bất cứ điều gì có liên quan, đặc biệt là vì bạn không Dường như không biết loại "cơ sở hạ tầng" nào bạn sẽ làm việc với ... hãy tưởng tượng đó là một máy tính lớn chạy tất cả các loại zLinux ... với "z" là một phím tắt cho thời gian chết không (không thể phủ định). .. để giữ máy bay trên không ...

— Pierre.Vriens

@ Pierre.Vriens, Bình luận vui nhộn. Hãy yên tâm, điều này không thực sự xảy ra hoặc tôi đang bận rộn với tài khoản LinkedIn của mình ngay bây giờ, nhưng tôi không nghĩ rằng kiểu di chuyển này sẽ là phi thường trong những ngày này. Một số tổ chức có thể thực sự có lợi bằng cách giao dịch một số nhân viên giữa các nhóm phát triển và các op, và tôi chắc chắn rằng một số tổ chức làm điều đó trong quá trình lái xe để "thực hiện DevOps".

— Stephen C

8

Vì bạn đã gắn thẻ câu hỏi này là "văn hóa", tôi cho rằng bạn không quan tâm đến một ứng dụng cụ thể, nhưng trong các câu hỏi rộng hơn về quy trình làm việc và quản lý.

Có lẽ tôi sẽ bắt đầu với "Cẩm nang DevOps"; đó là một tổng quan tốt về những điều khác nhau để xem xét, mà không cần lặn quá sâu.

"Giao hàng liên tục" của Jez Humble cũng thường được tham khảo; Tôi chưa đọc nhiều về nó, nhưng nó bao gồm các khái niệm về kiểm soát nguồn và tự động hóa các bản dựng.

Nếu bạn bắt đầu tham gia vào các ứng dụng ở quy mô (điều này có thể quá nhiều giả định), một cuốn sách hay khác là "Thực hành quản trị hệ thống đám mây" của Limoncelli et al.

— Stuart Ainsworth
nguồn

1

Tôi đã đọc khoảng 60% cuốn sách Limoncelli trước khi mất nó trong một lần di chuyển. Nó chắc chắn đã dạy tôi rất nhiều. Tôi cũng vừa mới bắt đầu "Dự án Phượng hoàng" của Gene Kim và cộng sự, đây là một bài đọc đáng ngạc nhiên trong khi cũng dạy rất nhiều.

— Stephen C

Tôi cũng thích cuốn sách Google SRE; nó thực sự phù hợp với tôi ở tổ chức của tôi hơn một số nội dung của DevOps, nhưng bản thân cuốn sách thì rời rạc. Bạn phải đọc nó theo thứ tự, chọn các chương hấp dẫn bạn và lướt qua phần còn lại.

— Stuart Ainsworth

7

Đây không phải là về DevOps, nhưng tôi giả sử phát triển phần mềm.

Tôi muốn hiểu văn hóa hơn

Chà, điều lớn lao trong phát triển thẳng (không có góc "DevOps") chắc chắn là "nhanh nhẹn", tức là đối với hầu hết các phần SCRUM. Bạn có thể làm điều tồi tệ hơn là ngồi xuống và đọc Tuyên ngôn Agile hoặc một đoạn mồi trên SCRUM hoặc Kanban cho các công việc sửa lỗi hàng ngày, sửa lỗi hàng ngày.

Bên cạnh đó, nói về "văn hóa", là từ phía nhà phát triển, chủ yếu là một điều cụ thể của DevOps. Vâng, chúng tôi cũng có những người truyền giáo của mình, đặc biệt là những thứ mới hơn như ruby hoặc golang, nhưng không cực đoan như trong thế giới DevOps / Cloud, nơi có những thay đổi mô hình thực tế đang diễn ra.

và cách bạn tiêu hóa số lượng tập tin tuyệt đối trong các dự án của bạn

Bản thân tôi đã làm việc trên các ứng dụng ruby không cần thiết, điều đó không có gì to tát. Hãy xem, những tập tin đó không chỉ nằm rải rác xung quanh, nhưng có một hệ thống phân cấp, quy ước và tất cả những thứ đó. Bạn không bao giờ thực sự cần phải có tất cả các tệp đó trong đầu tại một thời điểm duy nhất cho một dự án được thiết kế tốt. Nếu bạn làm việc tại một khu vực cụ thể, thường khá rõ ràng nơi các tệp có liên quan và bạn có thể phóng to chúng khá dễ dàng. Tương tự nên đi cho các môi trường lập trình hiện đại khác.

Trong các ứng dụng xấu, điều đó là khác nhau, nhưng sau đó, nhà phát triển sẽ không thực sự "tiêu hóa" bất cứ thứ gì, mà chỉ loạng choạng một cách điên cuồng cả ngày cho đến khi anh ta bỏ cuộc. ;)

— AnoE
nguồn