- vừa được xem lúc

Chuyện thay đổi

0 0 30

Người đăng: Rice

Theo Viblo Asia

Thay đổi là một thứ gì đó luôn luôn đáng sợ. Cách đây vài tháng mình có duyên đi làm cho một banking solution tên là X. Công ty cũng sử dụng docker container, artifact repository, docker swarm, ansible, etc. Nhưng, mình không thực sự cảm nhận được "DevOps culture" trong công ty.

Đây là quá trình release một version mới của công ty.

  • Developer làm một điều-kì-diệu gì đó.
  • Tạo jar file - pdf (500+ chương) - step by step.
  • Ném qua bên "DevOps" (IT Operation thì more accurate).
  • Nội dung của file pdf thường là:
cp a.jar b.jar
systemctl service abc restart

Hồi đấy làm được một thời gian, mình quyết định automate hơn (một chút). Mình tạo một script nhỏ để đọc file pdf, filter out command và chạy exec command theo list.

Đồng nghiệp nhìn xong liền nói:"No. It's too risky". ?

Thực tâm lúc đó mình thấy không phục, vì công ty còn có on-call duty. Tức nửa đêm lọc cọc dậy deploy một cái gì đó. Mình thấy cái đó ricky hơn. Tại mắt nhắm mắt mở, biết đâu gõ sai command, xong lại lọc cọc reverse lại thì coi như một đêm mất ngủ.

Mình hồi đấy còn lập hẳn cái bảng kiểu này. (Số má cũng hơi hoang đường chút xíu ? )

Description Success rate
Detach sever from cluster 99.6
Stop server 99.6
copy file 99.6
update configuration 99.5
start server 98.7
Attach back cluster 99.6

Nhìn qua thấy cũng không sao, nhưng nếu tính overall success rate thì:

P(T) = P(1)+P(2)+..P(n)
P(T) ~= 85%

Điều đó có nghĩa là, 4 giờ sáng, bạn tỉnh dậy, deploy cái của nợ đó. có 15% nó sẽ lỗi. Bạn ngồi nhìn màn hình. Màn hình nhìn bạn. Rồi bạn lại rollback old version. Thấy cuộc đời sao mà dở hơi quá.

Đã thật sự có trường hợp cái project đó đang ở version x.x.x.x.x.x.15, vì có bạn của nợ nào đó muốn seperate cluster cho rabbitmq mà mọi người phải lội ngược dòng về x.x.x.x.x.x.11. Mà cái project là microservice, cái version của của nợ này depends on version của của nợ kia. Thế là mấy nguyên 3 ngày mới rollback được. Sếp chửi, đồng nghiệp mắng, mình buồn.

Vậy mới nói, quần áo không làm nên thầy tu. Bạn có tải một đống tools về nhưng không dùng, hoặc dùng không hiểu quả thì cũng như không. Chuyên hôm nay đến đây thôi, hôm nào mình sẽ kiểu tiếp.

Somewhere, xx-xx-2021

Rice

P.s: Thật ra hồi đấy nhìn cái project mà version nó có tới 7 chữ số là mình đã thấy ớn, muốn té rồi. Giờ nghĩ vẫn sợ. ?

Bình luận

Bài viết tương tự

- vừa được xem lúc

Các mô hình phát triển phần mềm

1. Định nghĩa. Mô hình phát triển phần mềm hay quy trình phát triển phần mềm xác định các pha/ giai đoạn trong xây dựng phần mềm. Có nhiều loại mô hình phát triển phần mềm khác nhau ví dụ như:.

0 0 94

- vừa được xem lúc

Tìm hiểu về cách thiết kế Class Diagram

Trong 1 dự án, việc tổ chức code cũng như clean code là 1 điều rất quan trọng, nếu cách thiết kế các class hợp lý và rõ ràng sẽ giúp ích rất nhiều cho việc mở rộng và bảo trì sau này. Để làm được điều này chúng ta cần phải có 1 bản thiết kế Class Diagram thật sự hợp lý.

0 0 76

- vừa được xem lúc

Tôi trên con đường nỗ lực trở thành Agile Leader - Phần I

Mong muốn chia sẻ với mọi người về những trăn trở, những niềm vui, những bài học tích lũy, những mảnh kiến thức hay góp nhặt được trên con đường phấn đấu trở thành một Agile leader. Phần đầu này tôi muốn chia sẻ về định hướng, hay nói cách khác là điều gì cá nhân cần tập trung để trở thành một Agile

0 0 21

- vừa được xem lúc

9 ý tưởng cho buổi Retrospective hiệu quả!

Với những bạn đang vận hành dự án theo Scrum hoặc ít nhất đang cố gắng thử vận hành, ắt hẳn biết đến một scrum event quan trọng - Retrospective. Một event để scrum team cùng nhìn nhận lại lại cách thức làm việc, hợp tác với nhau hay nói chung là các vấn đề về quy trình, con người trong dự án.

0 0 53

- vừa được xem lúc

Mô hình phát triển phần mềm: Agile

1. Agile là gì. 2. Phát triển phần mềm theo Agile.

0 1 616

- vừa được xem lúc

Agile software development (Phần 2)

I. Whole-team approach (Phương pháp tiếp cận toàn đội). . Agile software development được xây dựng bởi đội gồm những người với nhiều mảng khác nhau.

0 0 29