Chuyện của sys

DevOps Blog

August 8, 2024

No Comments on
Categories: Uncategorized

Top 10 câu hỏi khi phỏng vấn DevOps Engineer ? – Phần 2 January 25, 2024

Tiếp tục series top 10 câu hỏi khi phỏng vấn DevOps Engineer . Sau một thời gian miệt mài research tìm kiếm thì mình xin mạn phép trả lời 5 câu hỏi đầu tiên . Nếu có gì sai sót mong các bạn bổ sung thêm .
1. TCP có bao nhiêu flags ? 
TCP tổng cộng có 6 flags bao gồm :
– Cờ SYN : Host A muốn gọi đến Host B thì trước tiên phải có qui tắc bắt tay 3 bước và cờ SYN là cờ đầu tiên cần được gửi đến Host B
– Cờ ACK : Sau khi đã nhận gói cờ SYN từ A gửi đến thì B sẽ gửi lại 1 cờ gọi là ACK xác nhận đã nhận được packet từ A .
– Cờ FIN : Là cờ sau khi kết thúc một kết nối Host A sẽ gửi đến B cờ này , và ngược lại .
– Cờ RST : Dùng để ngắt một kết nối . Nếu Host sender gửi cờ RST thì nghĩa là có gì đó không ổn với kết nối TCP hoặc là kết nối này không được cho phép
– Cờ PUSH : Cờ này được đảm bảo rằng các dữ liệu được ưu tiên xử lý ngay tại nơi gửi hoặc nhận . Thông thường thì dữ liệu gửi đén sẽ được đợi trong bộ nhớ đệm đến khi nhận đủ số lượng mới được xử lý .
– Cờ URG : Cờ URG giúp gửi những dữ liệu được ưu tiên trước . Khi packet được gắn cờ URG thì chúng ta được gửi đi trước dù trước đó có nhiều packet
2. TCP và UDP khác nhau như thế nào ? 

TCP

  • Đảm bảo rằng dữ liệu đến đúng như khi được gửi.
  • Kiểm tra lỗi các luồng dữ liệu.
  • Header 20 byte cho phép 40 byte dữ liệu tùy chọn.
  • Chậm hơn UDP.
  • Tốt nhất cho các ứng dụng yêu cầu độ tin cậy.

UDP

  • Không đảm bảo dữ liệu đến.
  • Không cung cấp tính năng kiểm tra lỗi.
  • Header 8 byte chỉ cho phép dữ liệu bắt buộc.
  • Nhanh hơn TCP.
  • Tốt nhất cho các ứng dụng yêu cầu tốc độ.
No Comments on Top 10 câu hỏi khi phỏng vấn DevOps Engineer ? – Phần 2
Categories: Linh tinh

Tản mạn chuyện cuối năm – 2023 January 19, 2023

Hôm nay là ngày làm việc cuối cùng của năm 2023 . Một năm đầy biến cố với năm tam tai đầu tiên . Lại một năm nhảy việc 3 lần , được gặp những đồng nghiệp mới đầy tài năng , những người sếp đầy nhiệt huyết và qua đó mình cũng đã được tiếp cận những công nghệ mà trước giờ mình chưa bao giờ được có cơ hội làm coi như trong cái rủi cũng có cái may .

Bài viết này cũng đánh dấu nhìn lại một năm qua mình đã làm được gì ?
Tháng 3 năm 2022 mình đã có một quyết định bước ngoặc của sự nghiệp của mình khi đã rời bỏ công việc làm hệ thống on premise khá nhàn rỗi không update được gì nhiều cho bản thân sau 2 năm gắn bó và tìm kiếm một cơ hội mới là làm các hệ thống về cloud theo trending của thị trường .
Tháng 4 năm 2022 mình đã được tiếp cận và làm việc với các hệ thống cloud của AWS . Tại đây mình đã biết và làm nhiều công nghệ mới điểm qua những công nghệ nổi bật như EKS , Terraform , Terragrunt , ArgoCD , Vault , Puppet …
Tháng 10 năm 2022 mình quyết định tìm kiếm một công việc mới đó là làm các hệ thống cloud của GCP . Sau khi đã làm việc với AWS thì việc tiếp cận với GCP cũng không quá khó khăn . Tại đây mình cũng đã biết và làm các công nghệ liên quan đến GCP điển hình như Anthos Config Management – tương tự như ArgoCD , ConfigConnector – tương tự như Terraform , GKE – tương tự như EKS và đặc biệt nhất đó là mình được làm việc với các công nghệ mới của Google như : Binary Authorization – Một công cụ trong flow Supply Chain Management Software , BeyondCorp Enterprise – Một giải pháp Zero trust của Google để secure application cũng như protection data trong doanh nghiệp .
Mặc dù những công nghệ kể trên mình đã tham gia , làm nhưng tự nhận thấy bản thân vẫn chưa thể nắm toàn bộ tất cả công nghệ trên trong thời gian ngắn như vậy và cần phải update nhiều hơn vào năm tới .

Lời cuối cũng xin chúc toàn thể anh em trong ngành IT nói chung và anh em đang làm trong lĩnh vực DevOps/SRE/System Engineer nói riêng có một năm làm việc thật hiệu quả , update thật nhiều kiến thức công nghệ mới để build những hệ thống có độ ổn định cao . Chào thân ái quyết thắng !!!!

No Comments on Tản mạn chuyện cuối năm – 2023
Categories: Uncategorized

Làm thế nào để tạo một Mysql Master-Slave khi đã có một server đang chạy standalone ? October 23, 2021

Hôm nay mình gặp 1 case chưa làm bao giờ đó là có một Mysql đang chạy standalone và muốn deploy 1 master slave cho nó . Mình thấy nó khá hay nên lên đây viết vài dòng cũng như là note lại cho bản thân .
Chuẩn bị :
– Stop tất cả các api , worker có liên quan tới việc write database .
– Tạo banner bảo trì cho site .
1 . Install mysql cùng version với version node standalone đang chạy
– Để kiểm tra version node đang chạy ta dùng lệnh :
# rpm -qa | grep mysql
mysql-community-common-5.7.34-1.el7.x86_64
mysql-community-libs-compat-5.7.34-1.el7.x86_64
mysql-community-libs-5.7.34-1.el7.x86_64
mysql-community-server-5.7.34-1.el7.x86_64
mysql57-community-release-el7-9.noarch
mysql-community-client-5.7.34-1.el7.x86_64
– Sau đó qua node slave cài đặt giống với version đó . Phần cài đặt database chắc mình không note ở đây vì nó khá basic chỉ cần yum install là được .
2 . Setup mysql slave .
– Việc setup cho node slave cũng khá đơn giản chỉ cần set password root giống với node đang chạy standalone là được . Sau đó start nó lên .
3. Setup cho node đang chạy standalone thành master node .
– Ta vào file config /etc/my.cnf add 2 dòng :
+ server-id = 1
+ log-bin = /var/lib/mysql/mysql-bin
– Sau đó ta restart mysql
– Tiếp tục login vào mysql của Master node tạo 1 user replicate :
CREATE USER slave_user@localhost;
SET PASSWORD FOR slave_user@localhost= PASSWORD(“slavepassword”);
GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’10.%.%.%’ IDENTIFIED BY “slavepassword”; 
– Sau đó ta check status master node bằng lệnh :
SHOW MASTER STATUS\G

4. Dump database từ node master node sau đó sync qua slave node và import .
mysqldump -u root -p –all-databases –master-data > /home/all-databases.sql
rsync -aurv /home/all-databases.sql root@slave-node:/home/
5. Setup cho slave node .
– Ta vào file config /etc/my.cnf add dòng :
+ server-id = 2
– Sau đó ta restart slave node .
– Import database vừa sync được từ master node vào mysql ở slave node .
mysql -u root -p < all-databases.sql
– Sau khi import toàn bộ database xong ta login vào lại mysql slave node và change config thành slave của master hiện tại .
mysql -u root -p 
stop slave;
CHANGE MASTER TO MASTER_HOST =’10.0.0.1′, MASTER_USER =’slave_user’, MASTER_PASSWORD =’slavepassword’, MASTER_LOG_FILE = ‘mysql-bin.000001’, MASTER_LOG_POS = 2564;
start slave;

Lưu ý : MASTER_LOG_FILE và MASTER_LOG_POS được lấy từ SHOW MASTER STATUS .
Vậy là chúng ta đã hoàn thành việc chuyển database từ standalone thành replicate master-slave . Nếu thấy hay hãy cho mình 1 like và 1 share nhé . Cảm ơn tất cả mọi người

No Comments on Làm thế nào để tạo một Mysql Master-Slave khi đã có một server đang chạy standalone ?
Categories: Linh tinh

Top 10 câu hỏi khi phỏng vấn DevOps Engineer ? – Phần 1 September 30, 2021

Chào các bạn , lại là mình đây sau một thời gian nghỉ dịch ròng rã 5 tháng ở quê thèm lắm cảm giác nhộn nhịp của thành phố .Trong thời gian rảnh rỗi mình có đi PV dạo một vài nơi . Và hôm nay mình xin phép được tổng hợp lại cho AE chút ít câu hỏi khi PV DevOps Engineer thì các manager/leader họ sẽ hay hỏi gì ?

  1. Trong TCP có bao nhiêu flags ?
  2. TCP và UDP khác nhau như thế nào ?
  3. DNS chạy ở layer mấy ?
  4. Khi nhập một domain https lên trình duyệt SSL được duyệt như thế nào ?
  5. Pod-1 ở node A gọi sang Pod-1 ở node B trong Kubernetes gọi ra sao ?
  6. CNI em đang dùng Kubernetes là gì ? Nó khác gì so với các CNI còn lại ?
  7. Trong Prometheus nếu không muốn xài mode pull thì có thể chủ động đẩy data tới server được không ? Bằng cách nào ?
  8. Có sử dụng iptables giữa các Node hay không ? Nếu có nếu cần add thêm 1 rule firewall thì làm như thế nào ?
  9. Sự khác nhau giữa readinessProbe và livenessProbe ?
  10. Trong HPA targetCPUUtilizationPercentage tính dựa trên percentage của chỉ số nào ?
No Comments on Top 10 câu hỏi khi phỏng vấn DevOps Engineer ? – Phần 1
Categories: Linh tinh

Những kiểu DevOps Engineer trong Ngữ Văn cấp 3 July 27, 2021

Chào các bạn , chắc hẳn các bạn cũng đang làm việc WFH trong chuỗi ngày chán nản cùng cực vì không được gặp đồng nghiệp , sếp , cũng như được nhậu nhẹt tụ tập cùng bạn bè vì COVID-19 diễn ra khá phức tạp . Hôm nay được một buổi dậy sớm mình lên đây viết đôi dòng về những trải nghiệm mình đã gặp trong quá trình làm việc và cũng như là đã tiếp xúc với những kiểu DevOps Engineer .
1 – DevOps Engineer – Chí Phèo
Trong hình ảnh một nhân vật quá nổi tiếng trong tác phẩm với nền văn học Việt Nam . Hắn chửi tất cả mọi người từ PM cho tới TechLead , chửi từ BackEnd cho tới FrontEnd chửi sang cả Tester có khi hắn chửi cả lead của hắn . Nhưng khác với Chí Phèo trong tác phẩm của Nam Cao là chửi không mục đích chửi cho thoả cơn say thì DevOps Engineer – Chí Phèo chửi , mục đích duy nhất của hắn là để rủi có thằng Chí Phèo nào thế chỗ của hắn sẽ không phải chửi hắn .
2 – DevOps Engineer – Lão Hạc
Trong hình ảnh một nhân vật quá ư là nổi tiếng trong tác phẩm cùng tên của Nam cao . Lão Hạc nhà ta là một người rất chi là cam chịu với chế độ phong kiến . Lão ta có thể làm bất cứ một thứ khi người ta cần . Lão cày ngày cày đêm chỉ để làm vừa lòng tất cả mọi người . Mỗi ngày của Lão ta thức dậy chỉ để làm những điều mà người khác muốn và không cần biết lí do tại sao mình phải làm như vậy.
3 – DevOps Engineer – Xuân tóc đỏ
Trong hình ảnh một nhân vật trong tác phẩm Số Đỏ của Vũ Trọng Phụng . Hắn ta là một người chuyên đú trend , đi trước thời đại và mồm mép . Hắn luôn tỏ vẻ hiểu biết nhưng chỉ giỏi chém gió nói 1 chỉ làm 0.5 đôi khi là 0 làm . Chuyên nịnh hót và dìm những người xung quanh để nâng cao bản thân .
4 – DevOps Engineer – Thiên Nga
Tại sao lại là Thiên Nga vì tôi có nghe thoang thoảng đâu đó một câu nói “hãy sống đẹp như những con thiên nga của Tchaikovsky” . Bạn thiên nga này luôn nghĩ về hệ thống , luôn muốn tốt cho nó , luôn muốn phát triển dồn toàn tâm toàn ý cho hệ thống của mình và là một người rất fair với teammate . Tóm lại nếu như bạn đang làm việc với những con thiên nga như này thì hãy trân trọng và hãy sống thật đẹp bạn nhé .
Mặc dù Văn mình không tốt viết cũng chẳng hay nên những dòng này chỉ mang mục đích giải trí nên mong mọi người có thể xem nó như một mẫu chuyện cười . Chúc mọi người có 1 kỳ làm việc WFH hiệu quả nhé^^.
No Comments on Những kiểu DevOps Engineer trong Ngữ Văn cấp 3
Categories: Linh tinh

Techtalk cuối tuần – GitOps April 11, 2021

Chào các bạn , hôm nay là một ngày cuối tuần khá là nhàn rỗi đối với mình .Vì thế hôm nay mình xin phép lên đây chia sẻ , trao đổi một chút về một khái niệm mới cũng không hẵn mới , nhưng cũ thì cũng chẳng phải là cũ đó là GitOps .
1) Vậy GitOps là gì ? 
Chúng ta có thể tách nghĩa của nó ra trong từ “GitOps” . Git là một source control để lưu tất cả các manifest , config , source code của các bạn . Ops là Operation là hệ điều hành ,  hiểu rộng hơn có thể là một Infrastructure . Vậy GitOps bạn có thể hiểu nôm na chúng ta thay vì phải thao tác trực tiếp trên Operation/Infrastructure thì chúng ta có thể thao tác tất cả ở trên Git .

2) Tại sao phải sử dụng GitOps ?
Quay về cách đây 5 năm hoặc thậm chí là 10 năm khi ta muốn thao tác cài đặt hàng loạt các package cho các servers thì chúng ta có thể ssh vào từng con server để cài đặt , hoặc các master thời đó có thể viết Shell Script hoặc xịn hơn là Ansible để thao tác . Nhưng một vấn đề gặp phải là các action này không lưu lại history , rollback rất khó khăn hoặc rất chậm , không an toàn khi thao tác với hệ thống và còn rất nhiều vấn đề khác mình sẽ trình bày ở bên dưới .
– Sử dụng GitOps sẽ giúp cho bạn có thể lưu được tất cả các action của thành viên trong team dựa vào cơ chế merge request của Git . Khi ai đó cần action một cái gì đó tới hệ thống thì sẽ phải pull repository về sau đó phải commit và merge request để các leader review sau khi approve thì action kia mới có effect .
– Sử dụng GitOps sẽ giúp cho bạn rollback một cách dễ dàng hơn bằng việc quản lí source tại Git .
– Sử dụng GitOps cũng là một cách để các bạn docs lại kiến thức của mình và có thể đọc code để xem lại bất cứ lúc nào .
– Sử dụng GitOps có thể giúp bạn đỡ phải login vào server để thao tác tránh rủi ro không đáng có .
– Apply GitOps sẽ giúp bạn và team của bạn tiết kiệm được rất nhiều thời gian bằng việc automation tất cả mọi thứ .
– Hơn nữa GitOps giúp team bạn gắn kết hơn làm việc hợp tác với nhau hơn bằng việc lưu tất cả các action ở Git.
3) GitOps hoạt động ra sao ?
Giả sử ở đây mình có một manifest helm bên dưới , bình thường mình sẽ phải chạy command line để apply một secret và configmap của mình tới cluster Kubernetes
helm upgrade secret-test ./secret \
–install \
–namespace=”test-namespace”
và lần khác cần chỉnh sửa gì mình lại phải vào folder này để chỉnh sửa các values rồi lại chạy command dài loằn ngoằn một lần nữa . Việc này khá là tốn thời gian cho bạn .

Vậy khi apply GitOps thì flow làm việc của mình sẽ như nào ?
Mình chỉ cần edit file mình cần edit và commit nó lên Git , còn lại Git sẽ tự làm tất cả việc còn lại . Bên dưới mình có vẽ một mô hình cơ bản về GitOps .

Developer edit config lên Git sau đó sẽ có CI sẽ run command dài loằn ngoằn để deploy tới K8s Cluster . Thật đơn giản phải không ? Nhưng sao phía CI/CD lại biết mình chạy command nào mà nó run được hay vậy ?  Vì các config sẽ được lưu ở 1 file có tên là .gitlab-ci.yml file này sẽ thực hiện tất cả các thao tác mà mình đã define từ trước . Nhưng bài viết này mình chỉ tập trung về GitOps nên có lẽ mình sẽ chia sẻ chi tiết hơn về Gitlab-CI .
Thực sự GitOps là khái niệm tuyệt vời để cho các team DevOps/System có sizing lớn làm việc cùng với nhau một cách hiệu quả nhất mà không bị conflict giữa các thành viên với nhau . Hi vọng qua bài viết này bạn có thêm một chút khái niệm về GitOps cũng như các GitOps hoạt động ra sao . Cảm ơn các bạn đã đọc bài , nếu thấy hữu ích hay cho mình 1 like để ủng hộ mình nhé . Have a nice weekend . 

No Comments on Techtalk cuối tuần – GitOps
Categories: Linh tinh

Tản mạn chuyện cuối năm February 11, 2021

Chào các bạn , lại là mình đây .Hôm nay là 30 tết cũng là ngày cuối cùng của năm 2020 theo tết âm lịch của người Việt Nam . Kết thúc một năm đầy biến động với những pha nhảy việc thần thánh của mình và những chuỗi ngày cực kì khó khăn trong năm 2020 khi đã nhảy việc tận 4 lần để tìm được chỗ mới cho mình . Hi vọng sẽ gắn bó thật lâu với công ty để có thể phát triển được những sản phẩm tốt nhất cho người Việt .

Lời cuối mình xin chúc AE DevOps/SysOps thật nhiều incident , thật nhiều challenge để có thể deal lương tốt với sếp trong năm tiếp theo , chúc cho cộng đồng DevOps/SysOps phát triển càng ngày càng mạnh , chúc cho gia đình , bạn bè người thân của các anh em thật nhiều sức khoẻ , may mắn và thành công trong cuộc sống .
Tại hạ xin cáo bút ở đây . HAPPY NEW YEAR LUNAR !!!!

No Comments on Tản mạn chuyện cuối năm
Categories: Linh tinh

Những thứ cần làm để trở thành 1 Linux system admin thành công? February 10, 2021

Nghe cái tựa đề là thấy có chút vấn đề rồi nhỉ?, tính ra thì khoảng hơn 1 năm nay mình chưa viết 1 bài nào mới cả, nhân dịp một đêm mất ngủ cùng với 1 bài viết được chia sẻ trên đây , mình xin phép được tóm tắt lại một số ý chính của bài viết cũng như vài suy nghĩ của mình về nghề nghiệp chính của mình hiện tại, 1 Linux System Administrator.
Như các bạn đã biết thì System Admin nói chung, Linux System Administrator  nói riêng thì là 1 vị trí luôn được các công ty săn đón nhiều nhất và mức độ cạnh tranh càng lúc càng cao, mức độ đãi ngộ cũng cực kỳ lớn, các topic tuyển dụng các vị trí này luôn hot và ngày càng có nhiều trung tâm cung cấp những khóa học nhanh nhất để trở thành 1 System Admin (à, tính ra chủ yếu người ta tuyển Devops, nhưng trong topic này mình không nói thêm về từ khóa này, #devops is bullshit) . Nếu bạn là 1 người có kinh nghiệm sử dụng Linux, đã và đang làm những công việc có liên quan, và muốn trở thành 1 Linux System Admin thành công, thì những điều dưới đây có thể sẽ giúp ích cho bạn.

1. Cài đặt môi trường

Đã là 1 Linux System Admin thì việc thành thạo việc cài đặt hệ điều hành cho máy tính cá nhân hay hệ thống máy chủ là 1 điều bắt buộc, tùy theo sở thích cá nhân mà mỗi người thường chọn cho mình 1 bản phân phối yêu thích, những người thích làm mọi thứ thường hay chọn Arch để khổ d*m, hoặc những bạn thích màu mè có thể chọn Mint, như cá nhân mình thì vẫn sử dụng Ubuntu cho laptop cá nhân ( do nhiều lần cài thử những thứ khác nhưng không được).
Và tất nhiên là sử dụng hệ điều hành hay môi trường nào bạn đều phải làm những thứ cần thiết như sau cài đặt, chia phân vùng, chia swap, mã hóa disk hay đặt mật khẩu BIOS, cấu hình firewall hay làm mọi thứ mình thích miễn sao có thể thoải mái sử dụng cho mục đích cá nhân và công việc.

Note: Hầu như mọi người đều quên mã hóa ổ cứng của họ.

2 + 3: Quản trị user và group, cài đặt và cấu hình các gói cần thiết

Đây thực sự là công việc thường xuyên của 1 Linux user bình thường, không cần nhất thiết là phải 1 Linux System Admin, tuy nhiên một số lưu ý về chính sách tạo mật khẩu, độ khó hay thời gian hết hạn, quyền hạn của user cũng như việc sử dụng các trình cài đặt cho mỗi bản phân phối Linux khác nhau.

Note: Có thể bạn chưa biết, chữ Y trong YUM là con chó màu vàng? (Yellowdog)

4 + 5: Linux Shell và Filesystem

Shell là cái vỏ sò hay dầu nhớt nhỉ? Dù nó là gì đi nữa thì cứ làm Linux Admin thì chính xác là phải thành thục nó, để tương tác với hệ thống thì bạn bắt buộc phải sử dụng Shell. Bash/Sh/Zsh/Fish là 1 số shell thường được các chuyên gia sử dụng, câu lệnh hay các đoạn script đều rất hữu ích cho công việc của bạn, cộng với những hiểu biết về hệ thống filesystem của Linux khiến bạn trở nên thành thục và hiểu sâu những thao tác mà bạn đang muốn làm với hệ thống của mình.

Large selection of isolated seashells and a starfish. Montage.

6 + 7: Cấu hình và quản trị network cùng với quản lý dữ liệu lưu trữ

Kiến thức về network cơ bản cần phải nắm rõ như TCP/IP, routing, switch (ý nói kiến thức CCNA?), một điều làm nên 1 System Admin giỏi chính là nắm rõ và hiểu sâu những điều cơ bản này tuy nhiên thì những khóa học này đã hơi lỗi thời, và đã qua trend đào tạo thì phải? 🙂
Data là 1 thứ gì đó cực kỳ quan trọng, trong bài viết sau mình sẽ nói về chủ đề này

8: Công nghệ ảo hóa

Đây thực sự là 1 lĩnh vực cực kỳ rộng và sâu, cần phải đổ rất nhiều công sức để hiểu được đâu là hypervisor đâu là containerized, đâu là VPS đâu là Cloud Server? ^^

9+10: Quản trị Backup và Disater Recovery

Việc lưu trữ dữ liệu cực kỳ quan trọng cũng như những bản backup của nó, chúng ta không cần phải nói quá nhiều về sự quan trọng của nó vì không phải ngẫu nhiên mà các giải pháp được ưu tiên nhất của các doanh nghiệp chính là việc xây dựng datacenter dự phòng chỉ để backup và phục hồi sau thảm họa.
Có rất nhiều bài báo viết về vấn đề này, ví dụ như code của bạn sẽ được bảo vệ hoàn toàn sau khi trái đất bị phá hủy và sẽ được khôi phục chạy lại ngon lành trên sao hỏa, hay việc google xây dựng hệ thống datacenter ở đâu đó Nam Cực hay Bắc Cực gì đó.
 
Trên đây là 10 điều trong 20 điều mà bài viết đề cập, hầu hết đây là những điều cơ bản những thường là cực kỳ quan trọng, nếu cơ bản nắm vững và ngon lành cành đào hết 10 điều này thì không cần đọc tiếp bài viết tiếp theo thì bạn đã có cơ hội để trở thành 1 Linux System Admin thành công rồi.
Tuy nhiên, những điều hay còn ở phía trước, chúc các bạn có một ngày làm việc cuối cùng của năm vui vẻ và đầy may mắn.

No Comments on Những thứ cần làm để trở thành 1 Linux system admin thành công?

Là một DevOps Engineer bạn sẽ chọn làm công ty product hay công ty outsource ? January 19, 2021

Chào các bạn , thời gian tết đến xuân về cũng đang cận kề , chắc AE System/DevOps cũng đang dần dần đóng băng và review hệ thống để chuẩn bị cho một mùa tết ấm no hạnh phúc với những chiếc bánh chưng , bánh giầy to bự từ công ty :))) . Mình thì năm nay nhảy việc 4 lần nên chắc cũng chả có bánh chưng chứ đừng nói là nhân thịt hay nhân ngọt 🙁 , đúng là một năm kinh tế buồn mà . 2H sáng chợt tỉnh giấc để chuẩn bị migrate hệ thống nhưng thấy thời gian còn nhiều quá nên lên đây bàn luận với các bạn về một vấn đề cũng khá nhiều tranh cãi “là System/DevOps Engineer thì nên làm công ty product hay là công ty outsource” . Dưới đây là quan điểm cá nhân của mình , nó có thể đúng hoặc sai , hi vọng rằng sẽ nhận được nhiều phản hồi từ các bạn để mình có thêm nhiều ý kiến hơn .

1. Sự khác nhau giữa một công ty outsource và một công ty product ? 
– Công ty outsource/outsourcing : Công ty anh A có ý tưởng , có tài chính và muốn thuê công ty anh B viết 1 soft hoặc project để công ty anh A có thể đem ra thị trường với danh nghĩa là của công ty anh A . Anh A có trách nhiệm thanh toán tiền còn công ty anh B có trách nhiệm hoàn thành yêu cầu soft/project cho công ty anh A , Sau khi hoàn thành xong soft/project công ty anh B bàn giao tất cả lại cho công ty anh A và sau đó tiếp tục tìm 1 công ty anh CDEXYZ để viết tiếp . Nói nôm na thì công ty outsource là công ty chuyên đào tạo những chiến binh tinh nhuệ để đi đánh thuê , đánh nhanh rút gọn hoàn thành tốt nhiệm vụ và nhận thù lao .
– Công ty product là công ty mà vừa có ý tưởng , vừa có tài chính lại vừa có nguồn nhân lực để có thể tự phát triển các soft/project cho chính công ty của mình . Nói nôm na thì công ty product là một công ty chuyên đào tạo những chiến binh tinh nhuệ để tự xây dựng đế chế riêng của mình từ đó có thể đưa ra thị trường tìm kiếm users và đem về nguồn thu nhập .
2. Công việc của một System/DevOps Engineer trong một công ty outsource và một công ty product là gì ? 
Mình thì thật là may mắn khi đã được làm việc và trải nghiệm được nhiều môi trường làm việc, từ outsource cho tới product cho tới lai giữa outsource và product .
Vì thế mình cũng muốn chia sẻ với các bạn về những trải nghiệm của mình khi làm việc tại 2 môi trường này .
– Tại công ty outsource công việc thường ngày của một System/DevOps Engineer thì sẽ phải handle một lúc nhiều projects cùng một lúc đôi khi là 10 – 15 projects công việc chủ yếu sẽ là họp cùng DEV team và khách hàng khi có một project mới được launch từ request của khách hàng . Sau đó lên plan chuẩn bị resource cho các môi trường DEV/STAG , triển khai CI/CD ,  setup môi trường , phối hợp cùng dev benchmark . Vì tính chất công ty outsource cần nhanh để sản phẩm release sớm giao cho khách hàng nên thường làm trong môi trường outsource các System/DevOps Engineer sẽ ít được động chạm tới performance/CCU của sản phẩm vì thực tế thì chỉ được làm ở môi trường DEV/STAG và ít đụng chạm tới real users .
– Tại công ty product công việc thường ngày của một System/DevOps Engineer sẽ vất vả hơn nhiều mặc dù thì có thể handle một lúc ít projects cùng lúc hơn . Chủ yếu sẽ làm việc trực tiếp với DEV team và team leader khi có một project mới được launch từ request của team product . Sau đó team System/DevOps và team DEV sẽ phải họp lên plan chuẩn bị resource cho việc launch sản phẩm ra ngoài , triển khai CI/CD , setup môi trường , benchmark . Vì tính chất là công ty product nên các System/DevOps Engineer cần phải làm việc với tinh thần trách nhiệm cao , phải on call 24/7/365 khi các services production có sự cố hoặc bị die thì phải xử lí ngay lập tức , tránh việc downtime lâu ảnh hưởng tới người dùng đang sử dụng bên ngoài  . Nếu làm cty product mà có incident report thì quả là 1 cực hình, stress triền miên khi lỗi không thuộc về mình mà phải đi report 😄
– Như mình đã nói ở trên thì vẫn AE System/DevOps Engineer còn làm trong một môi trường khác nữa là lai giữa hai môi trường . Nói nôm na thì công ty khách hàng sẽ thuê bạn về làm việc vận hành cho sản phẩm product của họ thường thì những AE làm trong khoảng lai giữa hai môi trường outsource và product này sẽ là những người khá là master trong việc vận hành sản phẩm cũng như phát triển hệ thống . Vì khách hàng thường sẽ giao cho bạn những công việc khá là khó khăn cũng như độ trách nhiệm cực cao . Thì ở môi trường này , các AE System/DevOps Engineer sẽ làm việc như một người lính đánh thuê chuyên nghiệp và cũng vừa là một người xây dựng đế chế riêng của mình . Riêng mình thì khá thích làm việc ở môi trường này , vì thường sẽ được làm việc remote và mức đãi ngộ khá là cao từ công ty thuê .
3. Các điểm tốt và không tốt khi làm việc tại một công ty outsource và một công ty product là gì ?
– Công ty outsource :
Điểm tốt :
– Sẽ được làm được nhiều công nghệ mới , tiếp cận khá nhiều flow làm việc mới .
– Được make color hệ thống .
– Thời gian không gò bó có thể vứt laptop ở nhà mà đi chơi với gấu mà không cần phải lo hệ thống chết giữa chừng .
Điểm không tốt : Làm nhiều công nghệ mới những sẽ không làm sâu , không hiểu sâu sẩn phẩm của mình , vì thường sản phẩm có vòng đời khá ngắn nên chỉ làm cho xong rồi tiếp tục với các sản phẩm mới từ request khách hàng .
– Công ty product : 
Điểm tốt :
– Sẽ được làm một số công nghệ là stack của công ty nhưng sẽ được đào sâu nghiên cứu .
– Vì tính chất vòng đời của sản phẩm khá là dài vì thế sẽ được nhìn thấy sản phẩm do mình owner phát triển từng ngày từng ngày đó là một điều cực kì hạnh phúc đối với những AE làm việc tại các công ty product .
Điểm không tốt :
– Sẽ ít được làm những công nghệ mới vì công ty product cần một sự ổn định cao cho nên  khi đưa một công nghệ mới vào tổ chức cần được cân đo đong đếm rất nhiều mới có thể apply vào được .
– Thời gian khá là gò bó khi phải on call 24/7/365 trực hệ thống khi có event , hoặc có một service mới được đưa ra ngoài .
4. Vậy AE System/DevOps Engineer nên chọn công ty nào để làm việc ?
Như mình đã giải thích rõ tính chất công việc ở trên rồi , mình nghĩ các bạn cũng đã có câu trả lời cho chính mình .
– Nếu bạn muốn làm nhiều công nghệ mới , nhiều thứ mới mẻ thì mình nghĩ nên chọn công ty outsource sẽ phù hợp với bạn .
– Nếu bạn muốn nhận nuôi một đứa con tinh thần muốn nhìn nó phát triển từng ngày , từng ngày thì đừng ngại ngần hãy đến với những công ty product mình chắc chắn bạn sẽ rất happy khi làm điều này .
– Còn nếu bạn làm vì TIỀN ok thoai :)) hãy chọn công ty nào trả lương cao nhất :)))
“Trên đây là đôi dòng chém gió của mình trong thời gian đợi migrate hệ thống giờ cũng đã 3h sắp tới giờ migrate hệ thống rồi . chúc các bạn có được sự lựa chọn đúng đắn cho nghề nghiệp của mình . Chúc bạn và hệ thống của bạn luôn luôn khoẻ mạnh . Cảm ơn các bạn , nếu thấy hay đừng ngại ngần để lại cho mình 1 like và share nhé . Mãi iuuu :*”

No Comments on Là một DevOps Engineer bạn sẽ chọn làm công ty product hay công ty outsource ?
Categories: Linh tinh