<div dir="ltr"><div><div><div>Hi anh Tuấn Anh và các anh trong BKT OpenCPS,<br></div>(em không chắc mail em có gửi tới BKT được không vì em nhớ là em không nằm trong ML của BKT)<br><br></div>Được anh Tuấn Anh chỉ đích danh nên trước khi thảo được 1 file tài liệu (A4) về phương pháp tiếp cận và kỹ thuật, em xin nêu ý kiến draft và một số câu hỏi của em ở đây trước, mong các anh giải đáp giúp để có thể clear hơn về định hướng.<br><br></div>Các phần em để trong ngoặc đơn là nói về kỹ thuật, có thể bỏ qua để nắm về hướng tổng quan tốt hơn ạ.<br><div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-27 10:27 GMT+07:00 Ta Tuan Anh <span dir="ltr"><<a href="mailto:anhtt@fds.vn" target="_blank">anhtt@fds.vn</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><snipped><br><div>
<br>
a) Kiểm thử tự động, tích hợp đóng gói phần mềm CI/CD<br></div></blockquote><div><br></div><div>Có 2 cách tiếp cận đối với mục CI/CD, một là sử dụng các dịch vụ online (như TravisCI hoặc CircleCI, trả thêm tiền để có hiệu năng chạy CI ổn định và tốt hơn); cách thứ 2 là tự xây dựng một cụm CI của riêng OpenCPS (dùng Jenkin hoặc Zuul).<br><br></div><div>Ưu điểm của cách 1 là tiết kiệm về chi phí và đã có PoC rồi (em, anh Khoa và Tú đã thử nghiệm với OpenCPS 1.8 chạy trên Travis), nhược điểm là sẽ khó customize và làm chủ hơn đối với các cách thức CI/CD phức tạp hơn về sau này.<br><br></div><div>Ưu điểm của cách 2 là mình hoàn toàn làm chủ về hạ tầng, kỹ thuật, nhược điểm là chi phí về mặt con người và vận hành sẽ tốn kém hơn.<br><br></div><div>Về kỹ thuật sâu hơn bên dưới, hiện tại mình đã ứng dụng Docker - đây là ở mức unit với service là OpenCPS, đối với OpenCPS v2.0 nên nâng lên một cấp về orchestration - có thể dùng kubernetes hoặc swarm để phục vụ cho các nhu cầu ở mục 2, 3, 4 bên dưới (update/upgrade, SLA...). Điều này cần OpenCPS v2.0 cần có một thiết kế về mặt kiến trúc hệ thống và mặt dịch vụ chi tiết và hợp lý hơn. Em recommend là chuyển dịch thiết kế hiện tại (SOA) về thiết kế micro-service.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
b) Đảm bảo an toàn an ninh thông tin hệ thống<br></div></blockquote><div><br></div><div>Phần này em không chuyên sâu, xin nhường cho các chuyên gia từ NetNam cũng như các thành viên khác.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
c) Đảm bảo hiệu năng, mức độ sẵn sàng cao hệ thống<br></div></blockquote><div><br></div><div>Để đảm bảo hiệu năng thì phụ thuộc vào mặt ... con người là chính. Cần Open thiết kế kiến trúc và từng thành phần để có thể chứng minh rằng thiết kế của OpenCPS là tối ưu, đảm bảo hiệu năng. Cần có thêm cơ chế review code để giảm thiểu rủi ro về ảnh hướng tới hiệu năng.<br><br></div><div>Để đảm bảo mức độ sẵn sàng cao, về mặt kiến trúc, OpenCPS v2.0 phải đảm bảo có thể kiểm soát được các race-condition; có nghĩa là nếu đồng thời có 2 request từ 2 user khác nhau cùng tương tác với 1 tài nguyên của hệ thống sẽ không gây ra tình trạng conflict. Đảm bảo được yêu cầu này thì OpenCPS v2.0 có thể triển khai thành phần HA/LB ở mode Active-Active.<br></div><div><br></div><div>Câu hỏi: chỉ tiêu đánh giá hiệu năng, mức độ sẵn sàng cao của hệ thống là bao nhiêu và như thế nào? Ví dụ về chỉ tiêu: hệ thống OpenCPS v2.0 triển khai trên hạ tầng cấu hình X (hardware, network..) bảo đảm chịu được tải tối thiểu Y CCU, để nâng lên mức Y^Y CCU cần theo công thức như sau. Ví dụ về mức độ sẵn sàng cao: nếu hệ thống gặp sự cố downtime do các service của OpenCPS gây nên thì số lượng connection/request/packet lost là X%.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
d) Giám sát đảm bảo vận hành chất lượng dịch vụ theo SLA<br></div></blockquote><div><br></div><div>OpenCPS v2.0 cần phải có thiết kế và tài liệu về mặt giám sát (monitoring/logging) và cảnh báo. Ngoài ra, ý d này hoàn toàn phụ thuộc vào ý c ở mặt SLA.<br><br></div><div>Về mặt kỹ thuật, thông thường monitoring các bên có thể sử dụng các giải pháp như Nagios, Cacti, Icinga, Zabbix.. nhưng phụ thuộc vào quyết định của mình ở ý a có thể sẽ là các giải pháp monitoring và cảnh báo khác như Prometheus (chuyên phục vụ cho container). Cảnh báo nên tối thiểu là có cảnh báo qua SMS, email và trung tâm điều hành chung của OpenCPS.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
Vì thời gian để chuẩn bị viết thuyết minh không nhiều, nên rất mong các chuyên gia trợ giúp gửi các thông tin cần thiết trong tuần này.<br>
<br>
Cám ơn mọi người,<br>
<br>
Tuấn Anh<br>
<br>
</div></blockquote></div><br></div><div class="gmail_extra">Em xin hết.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">-----BEGIN GEEK CODE BLOCK-----</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:medium"><span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">Version: 3.1</span><br style="color:rgb(0,0,0);font-family:monospace;font-size:medium"><span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C++++(++++)$ ULC++++(++)$ P L++(+++)$ E !W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ b+(++)>+++ DI- D+ G e++(+++) h-- r(++)>+++ y- </span><br style="color:rgb(0,0,0);font-family:monospace;font-size:medium"><span style="color:rgb(0,0,0);font-family:monospace;font-size:medium">------END GEEK CODE BLOCK------</span><br></div></div>
</div></div></div>