Sự khác biệt giữa Sysadmin và DevOps Engineering là gì?

Khi đi xin việc, thông thường bạn có thể tìm thấy hai loại công việc tương tự nhau: Kỹ sư Sysadmin và Kỹ sư DevOps .

Cả hai đều xử lý cấu hình máy chủ và đảm bảo hoạt động đáng tin cậy của hệ thống máy tính. Có thể khó để nói sự khác biệt giữa hai. Sự khác biệt chính giữa chúng là gì?

Chủ yếu DevOps không phải là một vai trò (khi được sử dụng như vậy nó là một từ thông dụng hơn là một vai trò thực sự).

DevOps gần như là một mô hình tổ chức nhằm phá vỡ silo giữa các nhà phát triển và hệ thống.
Mục tiêu chính là xây dựng các nhóm có nhà phát triển và hệ thống (thường cùng với người kiểm tra) chịu trách nhiệm về một sản phẩm (ứng dụng) từ định nghĩa của nó, quyết định kiến ​​trúc cho đến việc bảo trì sản phẩm này.
Mỗi thành viên trong nhóm sẽ là một phần của quyết định trong toàn bộ vòng đời của sản phẩm, một nhà phát triển sẽ thực hiện một số nhiệm vụ sysadmin trong sản xuất và một sysadmin sẽ tham gia vào giai đoạn thiết kế của sản phẩm để tránh bị ảnh hưởng từ quan điểm cơ sở hạ tầng ví dụ.

Về lý tưởng, một sysadmin cũng sẽ là một phần của nhóm phát triển sản phẩm, trong mã sysadmin trong thế giới thực về cấu hình xung quanh sản phẩm và các giải pháp giám sát, nhưng có thể nói lên mối quan ngại với các thành viên khác trong nhóm để tránh nhiều hiểu lầm về quá trình triển khai.

Phiên bản ngắn

DevOps là sự kết hợp giữa văn hóa tổ chức, cách thức làm việc Agile / Lean và tự động hóa phần mềm mà khi áp dụng vào Quản trị và vận hành hệ thống cho phép các chức năng này hoạt động với cùng mức độ nhanh nhẹn như các nhóm phát triển Agile hoặc Lean.

Phiên bản dài

Ý tưởng đằng sau DevOps xuất phát từ các cộng đồng Quản trị hệ thống, Vận hành và Agile, cụ thể, Patrick Debois đã trình bày tại Agile2008 với tựa đề 'Cơ sở hạ tầng Agile', nơi ông nhấn mạnh sự khác biệt giữa cách thức hoạt động của ba chức năng trong một tổ chức:

1. Nhóm phát triển Agile - Các nhóm Agile viết mã.
2. Nhóm quản trị hệ thống - Xây dựng cơ sở hạ tầng để chạy phần mềm.
3. Nhóm vận hành - Hỗ trợ các ứng dụng và cơ sở hạ tầng trong Sản xuất / Trực tiếp.

Đề xuất của Debois là thống nhất ba cách làm việc cùng nhau, cụ thể là chuyển các nhóm Quản trị Hệ thống và các nhóm Vận hành từ Mô hình Thác nước sang Mô hình Agile. Cuối cùng, Debois thiết lập DevOpsDays 2009 tại Ghent, Bỉ vô tình đặt ra cụm từ DevOps .

Ý tưởng về DevOps đã cộng hưởng với các tác giả của bộ sách VisibleOps: Gene Kim, George Spafford và Kevin Behr; người tiếp tục viết Dự án Phượng hoàng và Cẩm nang DevOps . Cả hai cuốn sách đều khám phá cách Agile và Lean có thể tác động tích cực đến các nhóm Quản trị và Vận hành Hệ thống.

Là một Kỹ sư DevOps đến từ nền tảng Hoạt động, bạn sẽ chuyển từ xây dựng và triển khai các máy chủ và phần mềm theo cách thủ công sang kịch bản cài đặt phần mềm lên các máy chủ của mình như BASH, PowerShell, Python, v.v ... Sau một thời gian, bạn sẽ nhận ra mát scripting được và bắt đầu khám phá những cách tinh vi hơn để tự động triển khai .

Cuối cùng, bạn sẽ giải quyết một Công cụ quản lý cấu hình Đầu bếp, Con rối, Ansible hoặc khác để giúp quản lý trạng thái của hệ thống của bạn. Khi các kỹ năng của bạn với việc tự động hóa triển khai ứng dụng và quản lý hệ thống đã hoàn thiện, cùng với các công cụ của bạn, gần đây bạn đã chuyển sang lĩnh vực ' Cơ sở hạ tầng như Mã ' và sử dụng nó để không chỉ tự động hóa việc triển khai phần mềm mà cả cơ sở hạ tầng và môi trường cần thiết để điều khiển phần mềm trong quá trình chuyển đổi sang đám mây của doanh nghiệp.

Bây giờ bạn đang nấu ăn bằng gas. Theo thời gian, bạn đã được giới thiệu những lợi ích của việc sử dụng công cụ trung tâm dành cho nhà phát triển như kiểm soát nguồn để quản lý các mô-đun, công thức nấu ăn và mẫu tạo nên kho công cụ quản lý và triển khai của bạn.

Khi bạn chuyển sang nhóm DevOps, bạn đã tiếp xúc với vòng đời phát triển phần mềm và khái niệm tích hợp liên tục . Boy các nhà phát triển đã phát hành các thay đổi nhanh chóng và để theo kịp bạn thấy mình làm việc chặt chẽ hơn với các nhà phát triển! Bạn đã trải nghiệm sự khẩn cấp được đặt ra cho nhóm phát triển để thay đổi mọi thứ TẤT CẢ THỜI GIAN chống lại mô hình hoạt động cũ là " nếu nó không bị hỏng, đừng sửa nó ". Không còn khoe khoang về thời gian hoạt động của hệ thống nữa, bạn đang vào cơ sở hạ tầng dùng một lần .

Bạn nhận thấy rằng việc chuyển sang DevOps không chỉ là làm việc với các nhà phát triển , hoặc sử dụng các công cụ và kỹ thuật mới , nhưng có một sự thay đổi văn hóa khác biệt trong nhóm, một sự thay đổi lớn trong tổ chức. Bạn đang làm việc như một nhóm gắn bó với các trách nhiệm chung , công cụ chung và mục tiêu chung .

Bạn đã sử dụng các kỹ năng của mình trong việc triển khai tự động và đưa chúng vào đường ống " CICD " được sắp xếp bởi một " máy chủ tích hợp liên tục " như Jenkins , Bamboo hoặc Code Pipeline . Bây giờ, khi các nhà phát triển đẩy mã mới, các tập lệnh, công cụ và mẫu của bạn sẽ tạo ra các môi trường mới theo yêu cầu, kích hoạt các khung kiểm tra để thực hiện công việc của họ và phá hủy các môi trường tiền sản xuất sau khi đèn xanh được bật lên, tuân thủ ý tưởng " giao hàng liên tục ".

Khi mã mới vượt qua các giai đoạn CICD, bạn, các nhà phát triển và doanh nghiệp có được sự tin tưởng rằng bản cập nhật sẽ không bị phá vỡ khi được phát hành vào sản xuất. Có một số cách để đi trước khi nhóm " triển khai liên tục ", bạn vẫn cần giải quyết các điểm tốt hơn để tự động hóa khả năng triển khai xanh / xanh và quyết định chủ yếu là kinh doanh. Hiện tại, bạn hài lòng rằng số lượng cuộc gọi lúc 3 giờ sáng đã giảm xuống và sự suy giảm của các ngày 7 và 1 của 2.

Ngay cả khi bạn nhận được một phần bảy, bạn sẽ không kéo dài cả đêm nữa với những người quản lý đang thở dốc - bạn có thể dễ dàng phát hành phiên bản trước thông qua đường ống CICD và đưa hệ thống trực tuyến trở lại theo thứ tự ngắn. Doanh nghiệp đã nhận thấy rằng sự ổn định của các hệ thống CNTT đã được cải thiện bất chấp tốc độ thay đổi .

Bạn sẽ ngạc nhiên về cách bạn quản lý các tài nguyên cần thiết để điều khiển phần mềm trong doanh nghiệp của bạn, đặc biệt là khi bạn nghĩ lại về cách thức sử dụng và lượng máu bạn để lại trên đường ray trong trung tâm dữ liệu ...

Sysadmin so với DevOps (quan điểm cá nhân)

Một số công ty nói về Dev, Ops và Test. Nếu một cái gì đó cần phải được kiểm tra thì họ nói: "Kiểm tra nên làm điều đó". Nếu một cái gì đó cần được phát triển, Dev sẽ làm điều đó và nếu phần mềm cần được triển khai, Ops sẽ làm điều đó.

Theo ý kiến ​​của tôi và những gì tôi đã trải nghiệm ở một số công ty là điều này dẫn đến một suy nghĩ "ném nó lên tường" dẫn đến xích mích giữa mọi người và các đội. Cá nhân, đôi khi tôi cảm thấy rằng mọi người làm việc cá nhân và nói rằng đây là những gì tôi đã làm, tôi không có gì để làm thay vì làm việc theo nhóm.

Theo tôi DevOps có nghĩa là mọi người trong nhóm chịu trách nhiệm và bận rộn với việc phát triển, thử nghiệm và vận hành. Không có tôi trong một nhóm và không có bộ phận riêng biệt. Mọi người nên phát hành. Tất nhiên có những đặc sản, nhưng theo tôi mọi người nên có thể làm ít nhất 25% một số công việc trong mọi lĩnh vực. Ví dụ: nếu ai đó là Nhà phát triển trở lại vào ban ngày thì người ta sẽ có thể thay đổi một số mã quản lý cấu hình, ví dụ: đầu bếp và phần mềm triển khai.

Tài liệu tham khảo

Sysadmin

Theo Wikipedia :

Quản trị viên hệ thống, hay sysadmin, là người chịu trách nhiệm bảo trì, cấu hình và vận hành đáng tin cậy của hệ thống máy tính; đặc biệt là máy tính nhiều người dùng, chẳng hạn như máy chủ.

Quản trị viên hệ thống tìm cách đảm bảo rằng thời gian hoạt động, hiệu suất, tài nguyên và bảo mật của máy tính mà họ quản lý đáp ứng nhu cầu của người dùng mà không vượt quá ngân sách.

Để đáp ứng những nhu cầu này, quản trị viên hệ thống có thể mua, cài đặt hoặc nâng cấp các thành phần và phần mềm máy tính; cung cấp tự động hóa thường xuyên; duy trì chính sách bảo mật; khắc phục sự cố; đào tạo hoặc giám sát nhân viên; hoặc cung cấp hỗ trợ kỹ thuật cho các dự án.

DevOps

Theo Wikipedia :

DevOps (một hợp chất được cắt xén của "phát triển" và "hoạt động") là một quy trình phân phối và phát triển phần mềm, nhấn mạnh vào giao tiếp và hợp tác giữa quản lý sản phẩm, phát triển phần mềm và các chuyên gia vận hành. Nó hỗ trợ điều này bằng cách tự động hóa và giám sát quá trình tích hợp, kiểm tra, triển khai và thay đổi cơ sở hạ tầng bằng cách thiết lập văn hóa và môi trường nơi việc xây dựng, kiểm tra và phát hành phần mềm có thể xảy ra nhanh chóng, thường xuyên và đáng tin cậy hơn.

DevOps

Công cụ DevOps

Quản trị viên hệ thống chịu trách nhiệm duy trì và định cấu hình máy chủ và trách nhiệm của họ là đảm bảo người dùng với hiệu suất, thời gian hoạt động và bảo mật mà họ đang tìm kiếm. Xác định vai trò của một kỹ sư DevOps khó khăn hơn một chút vì không có con đường sự nghiệp chính thức và bản thân DevOps có thể có nhiều hình thức.

Ví dụ, một kỹ sư DevOps có thể là một nhà phát triển quan tâm đến các hoạt động triển khai và mạng hoặc một quản trị viên hệ thống có niềm đam mê mã hóa và viết kịch bản. Việc chuyển đổi từ quản trị viên hệ thống sang kỹ sư DevOps không khó lắm, trên thực tế, bài viết này thực hiện rất tốt công việc mô tả quy trình.

Nhiều người thậm chí còn cho rằng việc chuyển đổi từ quản trị viên hệ thống sang kỹ sư DevOps là điều cần thiết vì vị trí quản trị hệ thống sẽ trở nên lỗi thời trong tương lai. Mặc dù có rất nhiều máy chủ cũ cần được bảo trì và các quản trị viên hệ thống sở hữu rất nhiều kiến ​​thức về bộ lạc trên mạng, vị trí sysadmin sẽ trở nên khan hiếm hơn trong tương lai.

Sẽ có những máy chủ mà bạn không nghe thấy đang chạy trong các trung tâm dữ liệu. Tất cả mọi thứ sẽ là phần mềm. Lưu trữ, mạng, hệ thống, bảo mật, trung tâm dữ liệu; SDN, tường lửa, NFV, lưu trữ, máy chủ, v.v ... Sysadins không có nền tảng phát triển phần mềm, trải nghiệm SDLC (tôi thậm chí không có nghĩa là kịch bản Perl, Powershell, v.v.) có thể sẽ biến mất. Các môi trường phân tán, có thể mở rộng và ảo hóa, phần lớn là đám mây, phát triển theo chiều ngang không theo chiều dọc.

Tôi dám nói Sysadmin phát triển theo chiều dọc, DevOps (hoặc OpsDev) phát triển theo chiều ngang. Bạn có thể thấy mô hình tương tự như thế nào microservice phát triển từ các khối nguyên khối. Tôi thà chọn kỹ sư DevOps từ nhóm phần mềm chứ không phải từ nhóm vận hành / hệ thống.

Bởi vì nhóm hoạt động / hệ thống chỉ chạy những gì nhóm phần mềm xây dựng.

• Sysadmin không xây dựng / biên dịch kernel Linux / FreeBSD / windows, v.v. giống như các kỹ sư phần mềm xây dựng / biên dịch các ứng dụng.
• Sysadmin không trải qua vòng đời phát triển phần mềm (SDLC).
• Sysadmin không phải là một phần của đường ống sản xuất (quy trình CI / CD).

• Sysadmin bắt đầu hoạt động sau khi CI / Giao hàng liên tục / Triển khai kết thúc.

  Và nếu bạn phá vỡ và chỉ định Triển khai / Giao hàng, đó có thể là một đường ống bị hỏng
  , nhóm phần mềm là nhóm hệ thống / người vận hành là người chạy / chăm sóc chủ yếu.

Có vẻ như không có máy chủ / hệ thống để quản trị, không cần sysadmin.

Máy chủ không điện toán là mô hình thực thi điện toán đám mây trong đó nhà cung cấp đám mây đóng vai trò là máy chủ, quản lý linh hoạt việc phân bổ tài nguyên máy. Giá được dựa trên lượng tài nguyên thực tế được sử dụng bởi một ứng dụng, thay vì dựa trên các đơn vị dung lượng được mua trước Máy tính không có máy chủ

Ai đó trong nhóm phần mềm đã biết cách xây dựng, duy trì ngay cả cách viết mã (SRE vs DevOps / OpsDev).

Tôi tự hỏi tại sao nó được gọi là DevOps mà không phải OpsDev? nó có liên quan đến hướng giữa hai không?

* Ở giữa hư không, tôi đã không bắt đầu viết về lưu trữ được xác định bằng phần mềm, đây là phản ứng với một nhận xét hiện đã bị xóa về nó *

Về lưu trữ được xác định bằng phần mềm

• Lưu trữ được xác định bằng phần mềm (SDS) là một thuật ngữ tiếp thị cho phần mềm lưu trữ dữ liệu máy tính để cung cấp và quản lý lưu trữ dữ liệu dựa trên chính sách độc lập với phần cứng cơ bản. Lưu trữ được xác định bằng phần mềm

• EMC đã công bố sản phẩm nguồn mở đầu tiên của mình: Project CoprHD. CoprHD là bộ điều khiển quản lý và tự động hóa lưu trữ được xác định bằng phần mềm và quyết định gần đây của EMC về nguồn mở là mấu chốt trong chiến lược của chúng tôi nhằm mang lại giá trị lớn hơn cho các doanh nghiệp toàn cầu khi chúng tôi bước vào một lĩnh vực tăng trưởng và thay đổi cực độ. Là công ty hàng đầu thế giới về lưu trữ và quản lý thông tin, nó sẽ điều khiển EMC dẫn đầu về Lưu trữ Xác định Phần mềm (SDS) .

• CoprHD là một bộ điều khiển lưu trữ và nền tảng API được xác định bằng phần mềm nguồn mở. Nó cho phép quản lý dựa trên chính sách và tự động hóa tài nguyên lưu trữ trên đám mây cho các nhà cung cấp lưu trữ khối, đối tượng và tệp CoprHD