zombie - những xác chết biết đi mà không thể kill

top 

top là câu lệnh để hiển thị các process đang chạy trên một máy tính *NIX.
Trên Windows sử dụng chương trình "Task Manager" để làm nhiệm vụ tương tự.

top rất dễ dùng, gõ `top` rồi ngồi nhìn màn hình update thông tin mỗi 3s, và bấm q để kết thúc.

Thế nhưng top cũng là một chương trình chứa rất nhiều thông tin, mà hỏi ra mỗi dòng có nghĩa là gì, cũng đủ để viết vài bài thật dài...

htop là một lệnh tương tự top, nhưng có giao diện dòng lệnh thân thiện hơn, màu mè hơn. htop không được cài sẵn trên mọi máy tính giống như top, người dùng phải tự cài thêm.

$ whatis top
top (1)              - display Linux processes

kill - signal trên OS: SIGINT vs SIGTERM vs SIGKILL vs SIGHUP

kill

Lệnh kill không lạ gì với người dùng Linux/MacOS. Ngay từ những ngày đầu học dùng dòng lệnh trên các hệ điều hành này, người dùng đã biết dùng kill để "giết" một chương trình đang chạy (một process).

Câu lệnh này quá cơ bản, dẫn đến dễ bị bỏ qua việc tìm hiểu nó kỹ càng.

Để kill 1 chương trình đang chay, người dùng sẽ tìm PID (process ID - một số nguyên dương được hệ điều hành cấp cho chương trình lúc bắt đầu chạy) bằng lệnh:

ps xau | grep tên_chương_trình

Ví dụ:

$ ps xau | grep -i firefox
hvn      12537  8.9  4.4 3202268 358612 ?      Sl   23:17   0:47 /home/hvn/Downloads/firefox/firefox-bin

12537 chính là số PID. Sau đó gõ lệnh:

kill 12537

và nếu chương trình vẫn chạy, thì dùng biện pháp mạnh:

kill -9 12537 

sẽ đảm bảo nhanh, gọn, sạch sẽ, xong.

Nhưng bên dưới là cả một chủ đề không quá đơn giản đến vậy.

Để trở thành DevOps Engineer

DevOps là một từ khóa công nghệ cực hot trong khoảng 2015-2018, đánh dấu
sự thay đổi về quy trình phát triển phần mềm trên toàn Trái Đất. Tại thời điểm
viết bài (2019-05), vị trí này đã có mặt ở hầu hết các công ty công nghệ tại
Việt Nam.

Bài viết này giải thích các khái niệm liên quan tới DevOps, đưa ra một giáo
trình để trở thành DevOps Engineer.

## DevOps là gì

DevOps không có định nghĩa chính thức, cũng không có định nghĩa rõ ràng, nó
là một khái niệm mới tự dưng xuất hiện, chưa từng có trước đây.
Cách hiểu phổ biến nhất, đây là một "cách/quy trình phát triển và vận hành phần mềm".
Được sinh ra từ việc khắc nhập 2 chữ: DEVelopment (phát triển) - OPerationS (vận hành).

### Quy trình phát triển phần mềm truyền thống

Lập trình viên code, code xong chuyển qua cho SysAdmin cài đặt (deploy), QA sẽ
tham gia kiểm tra chất lượng, nếu OK, SysAdmins sẽ mang đi deploy trên hệ thống
chạy thật, nếu gặp lỗi / report bởi người dùng, SysAdmin sẽ chuyển lại cho
developer sửa. Vòng lặp quy trình này thường mất nhiều thời gian trong tất cả
các khâu, tối thiểu mỗi khâu mất 1 tuần.

Dev ---> SysAdmin deploy nội bộ ---> QA ---> Sysadmin deploy ----> Người dùng.
^-------------------------------------|--------------------------------|

Chú ý ở mô hình này, xảy ra một sự xung đột về lợi ích: Dev luôn muốn các tính
năng, code của mình được đưa tới người dùng nhanh nhất. SysAdmin luôn muốn
hệ thống ổn định nên sẽ không muốn mang code mới đi chạy (vì code mới luôn
có bug).

### Quy trình phát triển theo DevOps

Dev ---> DevOps --> QA ---> Người dùng
^----------|---------|----------|

Tăng tốc Django API Service tới 90% với cacheops

1. Code chạy đúng là được rồi mà?

Code chạy đúng thôi là chưa đủ, luôn phải tối ưu thêm về mặt tốc độ.

Bạn có thể viết code đẹp như tranh, nhưng nếu một request của khách mất đến 10s để xử lý, thì 99% là khách hàng của bạn sẽ bỏ đi ngay lập tức (trừ khi bạn là trang .gov hoặc khi bạn cần đăng ký tín chỉ).

Ok, bạn tiếp tục "outsource" những phần xử lý nặng nề cho Celery hoặc RQ để khách đỡ phải nhìn màn hình trắng. Nhưng kể cả vậy thì nó cũng không làm vấn đề biến mất. Nó chỉ giúp khách của bạn biết rằng ở bên dưới bạn vẫn đang vật lộn xử lý chứ không "chết hẳn". Thay vì màn hình trắng thì giờ là hình xoay xoay.

Và lúc đó, bạn cần phải "tối ưu" lại code của mình rồi.

Và sau khi vò đầu bứt tai ngồi đoán, imort pdb; pdb.set_trace() loạn xạ, thêm các kiểu đo đếm thời gian, bạn bó tay. Vì đó không phải cách bạn nên làm để tối ưu code.

2. Analysis