Vietnamese Professional - CCNP Automation

Vietnamese Professional - CCNP Automation https://www.forum.vnpro.org/ vi Sun, 07 Jun 2026 07:39:06 GMT vBulletin 60 images/misc/rss.png Vietnamese Professional - CCNP Automation https://www.forum.vnpro.org/ Kibana https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/441204-kibana Sat, 06 Jun 2026 08:08:07 GMT Distributed Logging: Kiến trúc 5 tầng giúp quan sát hệ thống Microservices hiệu quả Khi hệ thống còn là Monolith, logging thường chỉ đơn giản là... Distributed Logging: Kiến trúc 5 tầng giúp quan sát hệ thống Microservices hiệu quả

Khi hệ thống còn là Monolith, logging thường chỉ đơn giản là ghi dữ liệu vào file trên máy chủ. Nhưng khi chuyển sang kiến trúc Microservices, Cloud Native và Kubernetes, hàng chục hoặc hàng trăm service có thể tạo ra hàng triệu log mỗi ngày. Lúc này, logging không còn là một tính năng phụ trợ mà đã trở thành một thành phần cốt lõi của tính khả kiến Observability. Một hệ thống Distributed Logging được thiết kế đúng cách thường chia thành 5 giai đoạn chính.

1. Collection Stage – Thu thập log

Đây là bước đầu tiên của toàn bộ quy trình. Các Collector Agent được triển khai gần nguồn sinh log nhất, thường nằm trên các máy chủ vật lý, máy ảo, Container, Kubernetes Node. Collector có thể hoạt động theo nhiều cách như theo dõi file log, theo dõi sự thay đổi của file, cung cấp API để ứng dụng gửi log hoặc Subscribe vào các nguồn log. Mục tiêu của giai đoạn này là thu thập dữ liệu càng gần nguồn phát sinh càng tốt.

2. Forwarding Stage – Chuyển tiếp log

Sau khi thu thập, log sẽ được gửi đến một Log Aggregator.
Log Aggregator đóng vai trò tập trung dữ liệu từ nhiều nguồn khác nhau như từ Application, từ Database, từ Operating System, Web Server, Event Queue... Đây là bước biến hàng trăm nguồn log phân tán thành một luồng dữ liệu tập trung.

3. Storage Stage – Lưu trữ log

Các log sau đó được ghi vào hệ thống lưu trữ. Tùy theo quy mô hệ thống, nơi lưu trữ có thể là Local Storage, Shared Storage, Object Storage, Distributed File System. Tại đây doanh nghiệp thường thiết lập các chính sách Retention Period, Log Rotation, Data Lifecycle, Archiving Policy... Ví dụ các bạn có thể thấy các chính sách như Giữ log vận hành trong 30 ngày, giữ log bảo mật trong 1 năm, chuyển log cũ sang Object Storage giá rẻ....

4. Indexing Stage – Đánh chỉ mục

Đây là bước giúp việc tìm kiếm log trở nên thực tế. Thay vì đọc từng file log thủ công, hệ thống sẽ tạo chỉ mục theo Thời gian, Ứng dụng, theo địa chỉ Máy chủ, Mức độ nghiêm trọng, Correlation ID...
Sau khi được đánh chỉ mục, các công cụ như Elasticsearch có thể thực hiện Full Text Search, Analytics, Dashboard, Trend Analysis
trong thời gian gần như tức thì.

5. Alerting Stage – Cảnh báo

Đây là tầng thông minh nhất của hệ thống logging. Nó liên tục phân tích log để phát hiện các lỗi bất thường, các tấn công bảo mật, Service bị gián đoạn, tăng đột biến lưu lượng, Không nhận được log từ một máy chủ nào đó. ...Khi phát hiện sự kiện bất thường, hệ thống có thể thực hiện các hành động như Gửi Email, Gửi Slack, Gửi Teams, Tạo Incident Ticket, Kích hoạt Automation Workflow....

Những Best Practice quan trọng trong Distributed Logging

Chuẩn hóa nền tảng logging

Trong môi trường Microservices, các nhóm phát triển có thể sử dụng Java, Python, Go, Node.js. Tuy nhiên nền tảng logging nên được thống nhất. Nếu mỗi service sử dụng một giải pháp logging khác nhau, việc quản lý và phân tích log sẽ trở nên cực kỳ phức tạp.

Sử dụng Correlation ID

Một giao dịch có thể đi qua:
User → API Gateway → Service A → Service B → Database
Nếu không có Correlation ID, việc truy vết lỗi gần như là ác mộng.
Correlation ID được gắn vào mọi log liên quan đến cùng một request để dễ dàng theo dõi toàn bộ hành trình của giao dịch.
Đây là kỹ thuật gần như bắt buộc trong kiến trúc Microservices hiện đại.

Không tin tưởng nhiều nguồn thời gian

Một vấn đề rất hay gặp là lệch giờ giữa các máy chủ.
Ví dụ:
09:01:05 User được cập nhật
09:01:03 User được tạo
Rõ ràng đây là điều vô lý. Để tránh hiện tượng này, toàn bộ hạ tầng cần đồng bộ thời gian bằng NTP, Chrony, Enterprise Time Service
Và tốt nhất nên xem một nguồn thời gian là "nguồn sự thật" duy nhất.

Luôn giả định hệ thống logging sẽ hỏng

Đây là tư duy DevOps rất quan trọng. Logging Server cũng là một dịch vụ và hoàn toàn có thể gặp sự cố. Collector Agent nên tự Buffer dữ liệu, Cache cục bộ, Retry khi kết nối phục hồi. Nếu không, bạn sẽ mất chính những log quan trọng nhất vào lúc hệ thống gặp sự cố.

Ghi log có ngữ cảnh

Thông báo lỗi kiểu Error occurred gần như vô dụng vì chúng không cung cấp thông tin hữu ích. Một log tốt nên bao gồm:

Timestamp

Service Name

Function Name

Correlation ID

Stack Trace

Client IP

User Agent

Error Details

Thông tin ngữ cảnh càng đầy đủ thì thời gian xử lý sự cố càng giảm.

Hỗ trợ Query Log

Giá trị thực sự của logging không nằm ở việc lưu trữ log mà nằm ở khả năng trả lời câu hỏi. Ví dụ:

Service nào lỗi nhiều nhất trong giờ cao điểm?

API nào có thời gian phản hồi lâu nhất?

Người dùng từ quốc gia nào tạo nhiều lỗi nhất?

Sau khi deploy phiên bản mới thì tỷ lệ lỗi thay đổi ra sao?

Muốn trả lời được các câu hỏi này, hệ thống phải hỗ trợ truy vấn dữ liệu hiệu quả.

ELK Stack – Bộ công cụ phổ biến nhất cho Distributed Logging

Một trong những giải pháp được sử dụng rộng rãi nhất hiện nay là ELK Stack. ELK bao gồm ba thành phần chính:
Elasticsearch
Là công cụ lưu trữ, tìm kiếm và phân tích dữ liệu dựa trên Apache Lucene. Khả năng Full Text Search cực kỳ mạnh mẽ giúp truy vấn hàng tỷ bản ghi log.
Logstash
Là tầng thu thập và xử lý log. Logstash nhận dữ liệu từ nhiều nguồn, chuyển đổi định dạng và chuyển tiếp đến hệ thống lưu trữ.
Kibana
Là giao diện trực quan hóa. Kibana cho phép Xây dựng Dashboard, Theo dõi thời gian thực, Điều tra sự cố, Phân tích xu hướng.
Ngoài ra ELK còn sử dụng các Collector Agent gọi là Beats.
Phổ biến nhất gồm:

Filebeat: Thu thập log file

Metricbeat: Thu thập CPU, Memory, Disk, Process

Packetbeat: Thu thập lưu lượng mạng

Auditbeat: Thu thập sự kiện bảo mật

Luồng xử lý thường là:
Application
↓
Beats
↓
Logstash
↓
Elasticsearch
↓
Kibana

Góc nhìn DevOps

Nếu phải chọn một thuộc tính quan trọng nhất của Distributed Logging, câu trả lời không phải là định dạng dữ liệu, tính toàn vẹn dữ liệu hay khả năng tìm kiếm. Đó là Data Aggregation.
Bởi vì giá trị lớn nhất của Distributed Logging là đưa toàn bộ log từ hàng trăm hệ thống khác nhau về một nơi duy nhất. Chỉ khi dữ liệu được tập trung, chúng ta mới có thể thực hiện tìm kiếm, phân tích, cảnh báo và điều tra sự cố một cách hiệu quả.
Đây cũng chính là lý do mà trong các nền tảng DevOps, SRE, AIOps và DevSecOps hiện đại, hệ thống Logging luôn được xem là một phần không thể thiếu của nền tảng Observability.]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/441204-kibana Broker Topology https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440942-broker-topology Mon, 01 Jun 2026 11:08:24 GMT Broker Topology trong Event-Driven Architecture: Khi hệ thống không cần "nhạc trưởng"

Trong các bài trước, chúng ta đã tìm hiểu Mediator Topology, nơi mọi luồng xử lý đều được điều phối bởi một thành phần trung tâm (Event Mediator). Tuy nhiên, không phải hệ thống Event-Driven nào cũng cần một "nhạc trưởng".

Đó là lúc Broker Topology phát huy tác dụng.

Broker Topology khác với Mediator Topology ở chỗ không tồn tại một thành phần trung tâm chịu trách nhiệm điều phối toàn bộ quy trình xử lý. Thay vào đó, các sự kiện (events) tự nhiên nối tiếp nhau thông qua một Message Broker, thường được triển khai dưới dạng Message Queue như Kafka, RabbitMQ, NATS hoặc ActiveMQ.

Khi một sự kiện xuất hiện, nó được gửi vào broker. Một event processor phù hợp sẽ nhận sự kiện đó, thực hiện phần công việc của mình rồi phát sinh một sự kiện mới. Sự kiện mới tiếp tục được broker chuyển cho processor tiếp theo. Quá trình này tạo thành một chuỗi xử lý liên tục cho đến khi hoàn thành nghiệp vụ.

Điểm quan trọng là sau khi xử lý xong một event, processor không còn tham gia vào quy trình đó nữa. Nó chỉ biết công việc của mình và không cần biết toàn bộ luồng nghiệp vụ phía sau.

Một ví dụ dễ hình dung là chạy tiếp sức (relay race).

Mỗi vận động viên chỉ chạy một đoạn đường của mình rồi chuyền gậy cho người kế tiếp. Không ai cần biết toàn bộ cuộc đua diễn ra như thế nào, họ chỉ cần hoàn thành phần việc được giao. Trong Broker Topology, "cây gậy tiếp sức" chính là event.

Ví dụ trong quy trình triển khai máy ảo (VM Provisioning):

Event "VM Requested" được gửi vào broker.
Resource Allocation Processor nhận event và cấp phát tài nguyên.
Sau khi hoàn thành, processor phát sinh event "VM Resources Allocated".
Broker chuyển event này cho IPAM Processor.
IPAM Processor cấp phát địa chỉ IP và phát sinh event "IP Address Reserved".
Event tiếp tục được chuyển đến các processor khác để triển khai VM, cấu hình hệ điều hành và hoàn tất hệ thống.

Toàn bộ quy trình diễn ra mà không cần một bộ điều phối trung tâm.

Đây là mô hình rất phổ biến trong các hệ thống:

Microservices
Cloud-native applications
Kubernetes Operators
CI/CD Pipelines
Infrastructure Automation
Large-scale Event Streaming Platforms

Ưu điểm lớn nhất của Broker Topology là khả năng mở rộng độc lập, giảm sự phụ thuộc giữa các dịch vụ (loose coupling) và tăng khả năng chịu lỗi của hệ thống. Tuy nhiên, đổi lại việc theo dõi luồng xử lý và troubleshooting sẽ phức tạp hơn vì không có thành phần nào nắm toàn bộ workflow. Ôn tập nhanh

Vai trò của Event Channel trong Event-Driven Architecture là gì?

Đáp án đúng:

a. Phân phối sự kiện từ Event Emitters đến Event Consumers

Event Channel đóng vai trò là "đường dẫn giao thông" giúp các sự kiện được truyền từ nơi phát sinh (Producer/Emitter) đến nơi xử lý (Consumer/Processor), tạo nên nền tảng cho toàn bộ kiến trúc Event-Driven hoạt động hiệu quả.

Trong thế giới DevOps, Automation và Cloud-Native ngày nay, hiểu rõ sự khác biệt giữa Mediator Topology và Broker Topology là bước đầu tiên để thiết kế các hệ thống phân tán có khả năng mở rộng và tự động hóa ở quy mô lớn.
]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440942-broker-topology Mediator Topology https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440907-mediator-topology Sun, 31 May 2026 03:38:23 GMT Khi Event-Driven Architecture cần một "nhạc trưởng": Mediator Topology

Trong nhiều hệ thống tự động hóa hiện đại, không phải mọi sự kiện đều đơn giản đến mức chỉ cần nhận sự kiện rồi xử lý ngay. Có những quy trình gồm nhiều bước, có bước chạy song song, có bước phải chờ bước khác hoàn thành. Đây là lúc Mediator Topology phát huy tác dụng.

Hãy lấy ví dụ quen thuộc trong DevOps và Cloud Automation: triển khai một máy ảo (VM) mới. Quy trình này thường bao gồm nhiều bước như cấp phát tài nguyên, đặt trước địa chỉ IP, tạo máy ảo và cấu hình hệ điều hành. Một số bước có thể thực hiện đồng thời, trong khi một số bước bắt buộc phải thực hiện theo thứ tự. Chẳng hạn, không thể cấu hình hệ điều hành nếu máy ảo chưa được tạo xong.

Trong kiến trúc Mediator Topology, có bốn thành phần chính:

Event Queue là nơi tiếp nhận các sự kiện ban đầu (initial events). Đây thường là message queue hoặc hệ thống hàng đợi sự kiện.

Event Mediator đóng vai trò trung tâm điều phối. Thành phần này không trực tiếp xử lý nghiệp vụ mà chỉ biết quy trình cần thực hiện gồm những bước nào, bước nào chạy song song và bước nào phải chờ.

Event Channel là các kênh truyền tải sự kiện xử lý (processing events) từ Mediator đến các bộ xử lý tương ứng. Chúng thường được triển khai bằng message queue hoặc event stream.

Event Processor là các thành phần thực hiện nghiệp vụ cụ thể. Mỗi processor nên độc lập, tự chứa (self-contained), liên kết lỏng lẻo (loosely coupled) và chỉ đảm nhiệm một nhiệm vụ duy nhất.

Điểm quan trọng của mô hình này là sự phân biệt giữa:

Initial Event: sự kiện khởi đầu quy trình.
Processing Event: các sự kiện trung gian được Mediator tạo ra để điều phối các bước xử lý.

Quay lại ví dụ triển khai VM.

Hệ thống nhận được sự kiện "VM Requested". Event Queue chuyển sự kiện này đến Event Mediator. Mediator biết rằng trước tiên cần cấp phát tài nguyên và đặt trước địa chỉ IP. Do đó nó gửi đồng thời hai processing events đến:

VM Resource Allocation Processor
IPAM Processor

Hai processor này hoạt động song song để thực hiện việc đặt trước tài nguyên và địa chỉ IP.

Khi nhận được các phản hồi như:

"VM Resources Allocated"
"IP Address Reserved"

Mediator biết rằng các điều kiện tiên quyết đã hoàn tất và tiếp tục gửi sự kiện đến VM Provisioning Processor để tạo máy ảo.

Sau khi nhận phản hồi "VM Provisioned", Mediator mới kích hoạt bước cuối cùng là cấu hình hệ điều hành.

Quá trình tiếp tục cho đến khi toàn bộ workflow hoàn thành.

Điểm mạnh lớn nhất của Mediator Topology là khả năng orchestration. Thay vì để các service tự gọi lẫn nhau tạo thành một mạng lưới phụ thuộc phức tạp, toàn bộ luồng xử lý được điều phối tập trung bởi Mediator. Điều này giúp dễ quản lý workflow, theo dõi trạng thái xử lý và xây dựng các quy trình tự động hóa phức tạp trong Cloud, DevOps, Infrastructure Automation hay IT Service Provisioning.

Nếu Broker Topology giống như một hệ thống phát thanh nơi các thành phần tự lắng nghe và phản ứng với sự kiện, thì Mediator Topology giống như một dàn nhạc có nhạc trưởng, nơi mọi hoạt động đều được điều phối theo một kịch bản đã định trước.

Đây cũng là nền tảng kiến trúc xuất hiện rất nhiều trong các công cụ Workflow Engine hiện đại như Camunda, Temporal, Netflix Conductor, AWS Step Functions và nhiều nền tảng Orchestration trong môi trường Cloud Native.
]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440907-mediator-topology Xây dựng DashBoard dùng REST API https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440881-xây-dựng-dashboard-dùng-rest-api Fri, 29 May 2026 22:31:31 GMT Tự Xây Dựng Dashboard Riêng Cho Doanh Nghiệp: Tại Sao DevOps Và Automation Engineer Cần Hiểu REST API? Rất nhiều hệ thống hiện đại như Cisco DNA... Tự Xây Dựng Dashboard Riêng Cho Doanh Nghiệp: Tại Sao DevOps Và Automation Engineer Cần Hiểu REST API?

Rất nhiều hệ thống hiện đại như Cisco DNA Center, Kubernetes, GitLab, Jenkins, ServiceNow, VMware, Intersight hay các nền tảng Cloud đều cung cấp sẵn giao diện quản trị (dashboard) rất đẹp.

Nhưng thực tế doanh nghiệp thường không muốn nhân viên phải đăng nhập vào 5–10 hệ thống khác nhau chỉ để xem trạng thái hạ tầng.

Giải pháp phổ biến hiện nay là xây dựng Custom Dashboard – một bảng điều khiển riêng tập hợp dữ liệu từ nhiều hệ thống khác nhau thông qua API.

Đây cũng là lý do vì sao REST API trở thành một trong những kỹ năng quan trọng nhất đối với DevOps Engineer, Platform Engineer, Cloud Engineer và Network Automation Engineer.

Dashboard và Back-End Giao Tiếp Với Nhau Như Thế Nào?

Trong kiến trúc ứng dụng hiện đại, phần giao diện người dùng (Front-End) thường không truy cập trực tiếp vào cơ sở dữ liệu.

Thay vào đó, Front-End gửi yêu cầu đến Back-End thông qua API.

Mô hình đơn giản:

Frontend Dashboard → REST API → Backend Service → Database

Khi người dùng nhấn vào một đối tượng trên giao diện, Dashboard sẽ gửi yêu cầu API đến hệ thống phía sau để lấy dữ liệu hoặc cập nhật trạng thái.

REST API Là Gì?

REST (Representational State Transfer) là một phương pháp xây dựng API trên nền giao thức HTTP/HTTPS giúp các thành phần ứng dụng giao tiếp với nhau.

REST trở thành tiêu chuẩn thực tế cho các ứng dụng web nhờ các ưu điểm:

Nhẹ (Lightweight)
Dễ triển khai
Không phụ thuộc nền tảng
Khả năng mở rộng cao
Hỗ trợ hầu hết ngôn ngữ lập trình

Bất kỳ thiết bị nào có khả năng gửi HTTP Request đều có thể sử dụng REST API:

Linux
Windows
macOS
Smartphone
Tablet
Thiết bị IoT

Các Phương Thức REST API Quan Trọng

REST sử dụng mô hình Request – Response của HTTP.

Các phương thức phổ biến gồm:

GET

Dùng để đọc dữ liệu.

Ví dụ:
GET /users/32

Truy vấn thông tin người dùng có ID là 32.

POST

Tạo dữ liệu mới.

Ví dụ:
POST /users

Tạo một người dùng mới.

PUT

Cập nhật toàn bộ đối tượng.

Ví dụ:
PUT /users/32

PATCH

Cập nhật một phần đối tượng.

Ví dụ:
PATCH /users/32

DELETE

Xóa dữ liệu.

Ví dụ:
DELETE /users/32

Dữ Liệu Được Trao Đổi Như Thế Nào?

Phần lớn REST API hiện nay sử dụng JSON.

Ví dụ phản hồi từ API:
{
"id": 32,
"name": "John Doe",
"email": "john@example.com"
}

Front-End chỉ cần đọc dữ liệu JSON và hiển thị lên màn hình.

Ngược lại, khi người dùng nhập dữ liệu trên giao diện, Dashboard sẽ đóng gói dữ liệu thành JSON rồi gửi lại Back-End bằng POST, PUT hoặc PATCH.

Khi Doanh Nghiệp Muốn Tạo Dashboard Riêng

Đây là tình huống rất phổ biến.

Ví dụ doanh nghiệp đang sử dụng:

Cisco DNA Center
VMware
ServiceNow
GitLab
Jenkins

Mỗi hệ thống đều có dashboard riêng.

Nhưng ban lãnh đạo muốn một màn hình duy nhất để theo dõi:

Tình trạng mạng
Trạng thái CI/CD
Ticket sự cố
Tài nguyên Cloud
Hiệu năng ứng dụng

Lúc này đội DevOps sẽ xây dựng một Dashboard riêng và tích hợp với các hệ thống thông qua API.

Mô hình này thường được gọi là:

Single Pane of Glass

Tức là một màn hình duy nhất để quan sát toàn bộ hệ thống.

Ví Dụ Thực Tế Với Cisco DNA Center

Cisco DNA Center cung cấp Dashboard quản lý mạng doanh nghiệp tập trung.

Nền tảng này hỗ trợ:

Thiết kế mạng
Provisioning
Policy
Monitoring
Assurance
Automation

Điều thú vị là dashboard mặc định của DNA Center cũng đang sử dụng chính API của hệ thống để lấy dữ liệu hiển thị.

Do đó nếu muốn tạo dashboard riêng, chúng ta chỉ cần gọi lại các API tương tự.

Northbound API Và Intent API

Trong các hệ thống quản lý mạng hiện đại thường có hai hướng API:

Southbound API

Giao tiếp xuống thiết bị.

Ví dụ:

NETCONF
RESTCONF
gNMI
SNMP

Northbound API

Cho phép ứng dụng bên ngoài truy cập vào hệ thống.

Trên Cisco DNA Center, Northbound API được gọi là:

Intent API

Intent API cung cấp khả năng điều khiển mạng ở mức mục tiêu kinh doanh (business intent) thay vì phải thao tác trực tiếp trên từng thiết bị.

API này sử dụng:

HTTPS
JSON
GET
POST
PUT
DELETE

Xác Thực API Bằng Token

Hầu hết hệ thống hiện nay đều yêu cầu xác thực.

Cisco DNA Center sử dụng cơ chế Access Token.

Bước đầu tiên là lấy token:
POST /dna/system/api/v1/auth/token

Kèm theo:

Username
Password

Nếu thành công hệ thống trả về:
{
"Token": "eyJ0eXA..."
}

Sau đó token được sử dụng trong header:
X-Auth-Token: eyJ0eXA...

cho các API tiếp theo.

Đây là mô hình rất phổ biến hiện nay và cũng xuất hiện trên:

Kubernetes
GitLab
ServiceNow
HashiCorp Vault
Cisco Intersight
Public Cloud APIs

Lấy Inventory Thiết Bị Từ DNA Center

Ví dụ lấy danh sách thiết bị:
GET /dna/intent/api/v1/network-device

Kết quả trả về là JSON chứa:

Hostname
Model
Serial Number
Software Version
Role
MAC Address
Uptime

Ví dụ:
{
"hostname": "cat_9k_1",
"type": "Cisco Catalyst 9300",
"role": "ACCESS",
"softwareVersion": "16.12"
}

Dashboard có thể đọc JSON này và hiển thị dưới dạng:

Bảng thống kê
Biểu đồ
Topology
Bản đồ mạng

Tích Hợp API Bằng Python

Trong thế giới Automation, Python gần như là lựa chọn mặc định.

Ví dụ lấy token:
import requests

r = requests.post(
'https://dnac/dna/system/api/v1/auth/token',
auth=('username', 'password')
)

token = r.json()['Token']

Sau đó gọi API:
headers = {
'X-Auth-Token': token
}

r = requests.get(
'https://dnac/dna/intent/api/v1/site-health',
headers=headers
)

Kết quả JSON có thể được:

Lưu vào Database
Đẩy vào Dashboard
Gửi sang Grafana
Phân tích bằng AI Agent
Tạo báo cáo tự động

REST Không Phải Là Lựa Chọn Duy Nhất

Ngoài REST còn nhiều công nghệ khác:

gRPC
SOAP
CORBA
RPC Frameworks

Tuy nhiên REST hiện vẫn là giao diện phổ biến nhất trong các hệ thống Cloud, DevOps và Network Automation.

Điều Mà Automation Engineer Nên Nhận Ra

Nhiều người nghĩ Automation chỉ là viết script cấu hình thiết bị.

Thực tế phần lớn công việc Automation hiện nay là:

Tích hợp hệ thống
Kết nối API
Thu thập dữ liệu
Chuẩn hóa dữ liệu
Xây dựng Dashboard
Tự động hóa quy trình vận hành

Nếu xem Infrastructure as Code là bước đầu tiên của tự động hóa, thì API Integration chính là bước tiếp theo để xây dựng Platform Engineering và AIOps.

Hầu hết các nền tảng hiện đại như Kubernetes, Cisco Catalyst Center (DNA Center), Intersight, GitLab, Jenkins, ServiceNow hay Public Cloud đều xoay quanh API. Người hiểu API sẽ có khả năng kết nối các hệ thống này thành một nền tảng thống nhất, thay vì quản trị từng sản phẩm riêng lẻ.

Nguồn tham khảo: Cisco DevNet ENAUTO, Cisco DNA Center Intent API Documentation.
]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440881-xây-dựng-dashboard-dùng-rest-api WebHook https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440712-webhook Tue, 26 May 2026 11:56:45 GMT Webhook là một khái niệm cực kỳ quan trọng khi bước vào thế giới automation, DevOps, NetDevOps hay tích hợp hệ thống. Nếu API truyền thống giống như...
Webhook hoạt động theo mô hình push, tức là server sẽ tự động gửi dữ liệu đến một endpoint đã được cấu hình sẵn mỗi khi có sự kiện xảy ra. Không cần polling liên tục, không cần viết script cứ vài giây gọi API kiểm tra trạng thái. Đây là lý do webhook được dùng rất nhiều trong monitoring, CI/CD, incident response, ChatOps và network automation.

Trong ví dụ từ Cisco Catalyst Center, webhook được dùng để phát hành (publish) các event notification như BGP Down, interface flap, unreachable device, assurance alerts… Khi có sự cố mạng, Catalyst Center sẽ đóng vai trò event producer, đóng gói dữ liệu dưới dạng JSON payload rồi gửi đến endpoint receiver của bạn thông qua HTTP POST hoặc đôi khi PUT.

Quy trình triển khai khá đơn giản. Trước tiên tạo một webhook destination trong Catalyst Center bằng cách khai báo tên, mô tả, URL của webhook receiver, chọn trust certificate nếu dùng HTTPS, chọn phương thức HTTP (thường là POST), cấu hình authentication nếu cần như Basic Auth hoặc token-based auth, rồi lưu lại.

Sau đó vào phần Event Notifications / Event Catalog, chọn sự kiện muốn subscribe, ví dụ Network Device Interface Connectivity - BGP Down, rồi dùng chức năng Try-It-Now để phát sinh test event. Catalyst Center sẽ gửi payload thử nghiệm đến tất cả destination đã subscribe.

Một điểm quan trọng là payload test có thể khác payload thật trong production. Vì vậy khi viết webhook receiver, đừng chỉ test với mock JSON đơn giản mà nên kiểm tra với event thực tế.

Ví dụ receiver có thể là:

Flask app
FastAPI service
Node.js Express endpoint
SIEM collector
Splunk HEC
ServiceNow
PagerDuty
Slack automation bot

Ví dụ luồng automation thực tế:

BGP Down → Catalyst Center phát webhook → Flask receiver nhận JSON → Python script parse event → gọi API tạo ticket ServiceNow → gửi cảnh báo Teams/Slack → trigger remediation playbook Ansible

Đây chính là nền tảng của event-driven automation.

Polling là mô hình “Are we there yet?”
Webhook là mô hình “I’ll call you when something happens.”

Với DevOps và NetDevOps, webhook không chỉ là notification mechanism. Nó là cầu nối để biến hạ tầng từ reactive sang autonomous automation.]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440712-webhook Event Notification Framework https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440638-event-notification-framework Sun, 24 May 2026 14:14:37 GMT Event Notifications Framework – “Hệ thần kinh cảnh báo” của Network Automation hiện đại Khi mạng ngày càng được tự động hóa, câu hỏi không còn là... Event Notifications Framework – “Hệ thần kinh cảnh báo” của Network Automation hiện đại

Khi mạng ngày càng được tự động hóa, câu hỏi không còn là “thiết bị có sự cố không?” mà là “sự cố đó được đẩy đến đúng hệ thống, đúng người, đúng workflow chưa?” Đây chính là vai trò của Event Notifications Framework.

Nhìn vào sơ đồ, ta thấy đây là một pipeline xử lý sự kiện khá điển hình trong các nền tảng quản trị mạng hiện đại như Cisco Catalyst Center.

Bắt đầu từ Network Infrastructure – gồm switching, routing, wireless – cùng với chính hệ thống quản lý (Catalyst Center System) liên tục sinh ra các event. Event có thể đến từ nhiều nguồn: thiết bị switch bị down, AP mất kết nối, CPU tăng cao, automation workflow fail, hoặc hệ thống assurance phát hiện trải nghiệm người dùng suy giảm.

Các event này đi vào Event Management System, nơi đóng vai trò như bộ não trung tâm. Tại đây có Event Catalog để định nghĩa các loại sự kiện, Subscription để quyết định ai sẽ nhận thông báo nào, và Runtime Dashboard để quan sát trạng thái theo thời gian thực.

Sau đó là lớp Notification Method – tức kênh phân phối cảnh báo. Không chỉ email truyền thống, framework hỗ trợ webhook (rất quan trọng cho automation), SNMP, syslog, Webex notifications, tích hợp với ServiceNow để tạo incident ticket, hoặc PagerDuty để đánh thức đội on-call lúc nửa đêm.

Điểm thú vị là mô hình này phục vụ trực tiếp cho business use case: NOC monitoring, ITSM workflow, dashboard analytics, managed services, centralized logging.

Ghi chú cuối slide rất thực tế: đây là 2 bước:

Cấu hình destination (nơi nhận cảnh báo)
Sau đó subscribe vào các event cần theo dõi

Đây chính là nền tảng để biến monitoring thụ động thành event-driven automation trong NetDevOps/AIOps.
]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440638-event-notification-framework Các giao diện lập trình https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440495-các-giao-diện-lập-trình Wed, 20 May 2026 11:16:44 GMT Programmable Interfaces trong Network Automation: Khi CLI không còn là con đường duy nhất Nhiều kỹ sư mạng bắt đầu sự nghiệp với CLI. Gõ lệnh,... Programmable Interfaces trong Network Automation: Khi CLI không còn là con đường duy nhất

Nhiều kỹ sư mạng bắt đầu sự nghiệp với CLI. Gõ lệnh, show output, copy-paste config. Trong nhiều năm, đó là cách vận hành mạng tiêu chuẩn.

Nhưng khi hạ tầng tăng lên hàng trăm hoặc hàng ngàn thiết bị, cloud-native architecture xuất hiện, telemetry real-time trở thành yêu cầu bắt buộc, thì CLI bắt đầu bộc lộ giới hạn.

Đây là lúc programmable interfaces bước vào cuộc chơi.

Hình trên mô tả khá rõ sự chuyển dịch từ mô hình quản trị mạng truyền thống sang model-driven programmability.

CLI chỉ là một interface, không phải toàn bộ hệ thống

Trên thiết bị Cisco IOS XE, chúng ta quen với:

CLI
SNMP
WebUI

Đây đều là những cách để tương tác với thiết bị.

Nhưng Cisco bổ sung thêm một lớp interface hiện đại hơn:

NETCONF
RESTCONF
gNMI

Điểm quan trọng:

Các giao diện này không thay thế hoàn toàn CLI, mà cung cấp additional methods để truy cập cùng một hệ thống dữ liệu cấu hình và operational state.

Hiểu đơn giản:

CLI là dành cho con người.

Programmable APIs là dành cho automation systems.

Ví dụ:

Con người:
show ip interface brief

Automation:
GET /restconf/data/ietf-interfaces:interfaces

Cùng mục tiêu.

Khác cách truy cập.

Vấn đề lớn của CLI trong automation

CLI hoạt động tốt cho tác vụ thủ công.

Nhưng automation thì khác.

CLI có nhiều hạn chế: 1. Output không có cấu trúc

CLI trả về text.

Ví dụ:
GigabitEthernet1 up up
GigabitEthernet2 administratively down

Automation script phải parse text.

Regex.
String matching.
Fragile logic.

Chỉ cần firmware upgrade làm thay đổi output formatting là script hỏng.

2. Không có schema chuẩn

CLI không định nghĩa rõ:

field nào tồn tại
kiểu dữ liệu là gì
đâu là config
đâu là operational state

Automation phải đoán.

3. Không transactional

Nếu push 50 dòng config:
conf t
interface gi1
description TEST
ip address ...
router ospf 1
...

Dòng 23 fail?

22 dòng trước vẫn đã apply.

Rollback thủ công.

4. Không phù hợp telemetry hiện đại

CLI polling:
show interface counters

không phải cách tốt để lấy metric liên tục mỗi giây.

YANG: trái tim của model-driven automation

Điểm cốt lõi trong slide:

YANG data models define the data

Đây là phần quan trọng nhất.

YANG không phải protocol.

YANG là data modeling language.

Nó mô tả:

cấu trúc dữ liệu
field
kiểu dữ liệu
hierarchy
constraints
config/state

Ví dụ logic:
interface
name
description
enabled
mtu

Automation không còn đoán nữa.

Thiết bị công bố schema rõ ràng.

Hai thế giới YANG phổ biến

OpenConfig

Vendor-neutral.

Được cộng đồng hỗ trợ:

Google
operators
multi-vendor ecosystems

Ví dụ:
/openconfig-interfaces:interfaces

Ưu điểm:

portable automation.

Một script dùng cho nhiều vendor.

Cisco Native

Cisco-specific.

Expose đầy đủ feature Cisco.

Ví dụ:

proprietary QoS
platform-specific knobs
advanced routing features

Tradeoff:

Powerful hơn nhưng lock-in cao hơn.

NETCONF: automation kiểu enterprise truyền thống

NETCONF dùng:

XML
SSH transport
RPC model

Thiết kế cho network configuration management.

Ví dụ:

get-config
edit-config
commit
lock datastore

Điểm mạnh:

transactional configuration.

Ví dụ:
candidate config
validate
commit
rollback

Điều CLI rất khó làm sạch sẽ.

NETCONF phù hợp khi:

enterprise automation
configuration orchestration
compliance enforcement

RESTCONF: thân thiện với DevOps

NETCONF mạnh.

Nhưng XML khá nặng.

RESTCONF sinh ra để hiện đại hơn.

REST principles:

GET
POST
PUT
PATCH
DELETE

Transport:

HTTPS

Payload:

JSON
XML

Ví dụ:
GET https://router/restconf/data/ietf-interfaces:interfaces

Nếu team của bạn quen:

Python requests
Postman
API testing
web services

RESTCONF dễ tiếp cận hơn NETCONF.

gNMI: sinh ra cho telemetry tốc độ cao

Nếu NETCONF/RESTCONF thiên về config management…

gNMI thiên về:

telemetry
streaming data
operational visibility

Nền tảng:

gRPC
protobuf
subscription model

Thay vì polling:
show interface counters

ta subscribe:
/interface counters stream

Thiết bị push dữ liệu liên tục.

Điều này cực kỳ quan trọng cho:

AIOps
observability
anomaly detection
closed-loop automation

Vì sao SNMP dần yếu thế?

SNMP từng là vua monitoring.

Nhưng có nhiều hạn chế:

Polling model:
manager hỏi → device trả lời

Không efficient ở scale lớn.

Data model hạn chế.

MIB complexity.

Telemetry granularity thấp.

Streaming telemetry với gNMI giải quyết tốt hơn nhiều.

Điều này không có nghĩa SNMP chết.

Nó vẫn tồn tại.

Nhưng rõ ràng không còn là tương lai dài hạn.

Intent-Based Networking kết nối mọi thứ

Slide có nhắc:

Intent-based Network Infrastructure

Đây là tầng orchestration cao hơn.

Workflow:

Intent:

"toàn bộ access switch phải bật NTP"

Automation system:

translate intent
map vào YANG models
push qua NETCONF/RESTCONF
verify operational state
remediate nếu drift

Đây là bước tiến từ:

manual configuration

→ automation scripts

→ intent-driven operations

Góc nhìn thực chiến

Nếu bạn là CCNA/CCNP:

Học RESTCONF trước.

Lý do:

dễ hiểu
JSON thân thiện
Postman test nhanh
Python automation đơn giản

Nếu bạn làm enterprise automation nghiêm túc:

NETCONF + YANG rất đáng đầu tư.

Nếu bạn làm observability/AIOps:

gNMI + streaming telemetry gần như bắt buộc.

Kết luận

CLI chưa chết. CLI sẽ còn sống rất lâu. Nhưng nếu automation strategy của bạn vẫn là:
send_command("show run")
parse with regex

thì bạn đang xây automation trên nền móng mong manh.

Tương lai của network automation nằm ở:

data models + APIs + telemetry-driven operations

Và đó chính là lý do programmable interfaces trở thành kiến thức bắt buộc với NetDevOps hiện đại.
]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440495-các-giao-diện-lập-trình Sync API và Async API https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440371-sync-api-và-async-api Mon, 18 May 2026 12:51:10 GMT Sync API và Async API – Khái niệm nền tảng mà DevOps Engineer và CCNA Automation cần hiểu Khi học về Network Automation, DevOps, Cloud... Sync API và Async API – Khái niệm nền tảng mà DevOps Engineer và CCNA Automation cần hiểu

Khi học về Network Automation, DevOps, Cloud Automation hay API Integration, một trong những khái niệm nền tảng nhưng cực kỳ quan trọng là sự khác nhau giữa Synchronous API (Sync API) và Asynchronous API (Async API).

Rất nhiều người mới học automation thường chỉ tập trung vào việc:

gọi API bằng Postman
viết Python requests
parse JSON
gửi GET hoặc POST

Nhưng trong môi trường thực tế, chỉ biết “gọi API” là chưa đủ.

Điều quan trọng hơn là phải hiểu:

API này phản hồi theo mô hình nào?

Bởi vì điều này ảnh hưởng trực tiếp đến cách bạn thiết kế automation script, xử lý lỗi, retry logic, timeout, thậm chí cả kiến trúc hệ thống.

Vì sao DevOps và Network Automation phải hiểu chuyện này?

Hãy tưởng tượng bạn viết một automation script để:

lấy danh sách interface từ router Cisco
deploy cấu hình cho 200 switch
trigger CI/CD pipeline
provision infrastructure trên cloud
tạo Kubernetes cluster
rollout application deployment

Có những việc hoàn thành gần như ngay lập tức.

Nhưng cũng có những việc mất:

10 giây
30 giây
vài phút
thậm chí hàng chục phút

Nếu không hiểu mô hình API, code automation rất dễ:

bị timeout
treo process
consume tài nguyên không cần thiết
retry sai cách
tạo duplicate request
gây lỗi production

Đây là lý do Sync vs Async là kiến thức nền.

Sync API là gì?

Synchronous API hoạt động theo mô hình đơn giản nhất:

Client gửi request.

Server xử lý.

Server trả kết quả.

Client chờ cho đến khi nhận response.

Luồng hoạt động:
Client → Request → Server
Client ← Response ← Server

Đây là kiểu giao tiếp “hỏi và trả lời ngay”.

Ví dụ:

Bạn gọi API lấy danh sách thiết bị từ Cisco controller:
GET /dna/intent/api/v1/network-device

Server trả về:
{
"response": [
{
"hostname": "SW1",
"managementIpAddress": "10.10.10.10"
}
]
}

Dữ liệu đã có ngay trong response.

Không cần gọi thêm API nào khác.

Ví dụ đời thường

Hãy tưởng tượng bạn gọi điện hỏi lễ tân khách sạn:

“Phòng 503 còn trống không?”

Lễ tân kiểm tra hệ thống.

Trả lời ngay:

“Còn.”

Đó là Sync.

Bạn hỏi.

Họ trả lời.

Kết thúc.

Đặc điểm của Sync API

Sync API phù hợp khi công việc xử lý nhanh.

Ví dụ:

query data
read configuration
health check
inventory lookup
telemetry retrieval
metrics collection

Trong DevOps:

Lấy trạng thái pod Kubernetes:
kubectl get pods

REST API:
GET /api/users

Prometheus:
GET /api/v1/query

Trong Network Automation:

RESTCONF:
GET /restconf/data/Cisco-IOS-XE-native:native

Lấy routing table:
GET /restconf/data/Cisco-IOS-XE-routing:routing-state

Ưu điểm của Sync API

Mô hình này dễ hiểu.

Dễ code.

Dễ debug.

Python code thường rất đơn giản:
import requests

response = requests.get(url, headers=headers)
data = response.json()

Không cần:

polling
task tracking
callback
job monitoring

Rất phù hợp cho người mới học CCNA Automation.

Nhược điểm của Sync API

Vấn đề xuất hiện khi công việc xử lý lâu.

Ví dụ:

deploy cấu hình cho hàng trăm thiết bị.

Provision site mới.

Push software image.

Run CI/CD pipeline.

Terraform provisioning.

Nếu server mất 2 phút để xử lý, client phải chờ.
waiting...
waiting...
waiting...

Khi đó:

HTTP session bị giữ mở.

Resource bị chiếm dụng.

Có nguy cơ timeout.

Ví dụ:
504 Gateway Timeout

Async API là gì?

Async API xử lý khác hoàn toàn.

Client gửi request.

Server nhận request.

Nhưng không xử lý xong ngay.

Thay vào đó server trả về:

task ID
execution ID
job reference
status URL

Ví dụ:
POST /dna/intent/api/v1/site

Server trả:
{
"executionId": "abc123",
"status": "scheduled"
}

Điều này có nghĩa:

Server nói:

“Tôi đã nhận việc. Hãy quay lại kiểm tra sau.”

Luồng Async

Client → Request → Server
Client ← Task ID ← Server

Client → Status Request → Server
Client ← Status ← Server

Client → Status Request → Server
Client ← Completed Result ← Server

Ví dụ đời thường

Bạn đặt mua 50 server cho data center.

Nhà cung cấp không thể giao ngay.

Họ trả:

“Đơn hàng #56789 đã được ghi nhận.”

Bạn kiểm tra sau:
Processing
Packing
Shipping
Delivered

Đây chính là Async.

Tại sao Async API rất quan trọng trong DevOps?

Trong DevOps, rất nhiều tác vụ là long-running operations.

Ví dụ:

CI/CD pipeline:
build
test
security scan
package
deploy

Terraform:
terraform apply

Cloud provisioning:

VM creation
Load balancer deployment
Database provisioning

Kubernetes:

Job execution
rollout deployment

Ansible Tower:

launch job template

Các tác vụ này không thể trả kết quả ngay.

Network Automation cũng dùng Async rất nhiều

Nhiều người nghĩ network API chỉ là GET configuration.

Thực tế không phải.

Ví dụ Cisco DNA Center:

template deployment
software image upgrade
compliance remediation
PnP onboarding
site creation

Các tác vụ này backend cần:

validate input
push workflow
update database
call controller services
execute provisioning tasks

Có thể mất nhiều thời gian.

Nên controller dùng Async.

DevOps Engineer phải code khác như thế nào?

Nếu Sync:
response = requests.get(url)
print(response.json())

Nếu Async:

Bước 1:
response = requests.post(url)
task_id = response.json()["executionId"]

Bước 2:

Polling:
while True:
status = requests.get(task_url).json()

if status["state"] == "COMPLETED":
break

Những thứ phải nghĩ khi xử lý Async

Timeout

Không thể polling mãi:
max_wait = 300

Retry

Nếu gặp:
429 Too Many Requests

hoặc:
503 Service Unavailable

Phải retry hợp lý.

Failure state

Task không phải lúc nào cũng thành công.

Ví dụ:
FAILED
ABORTED
PARTIAL_SUCCESS

Automation script phải xử lý.

Idempotency

Nếu request bị timeout:

Người mới thường gửi lại request.

Hậu quả:

duplicate deployment
duplicate VM
duplicate workflow

Production incident xảy ra từ đây.

CCNA Automation cần nhớ gì?

Nếu bạn học DevNet, CCNA Automation hoặc bắt đầu Network Automation:

Hãy nhớ:

GET thường là Sync

Ví dụ:
GET interfaces
GET routes
GET device inventory

POST/PUT cho provisioning thường dễ là Async

Ví dụ:
POST template deployment
POST software upgrade
POST site provisioning

Không phải lúc nào cũng đúng, nhưng đây là pattern phổ biến.

So sánh nhanh

Sync:

đơn giản
immediate response
blocking
phù hợp tác vụ nhanh

Async:

scalable
non-blocking
cần task tracking
phù hợp tác vụ dài

Kết luận

Khi học automation, nhiều người chỉ học:

“API là GET/POST.”

Nhưng tư duy production thực tế là:

API có execution model riêng.

Một DevOps Engineer hay Network Automation Engineer trưởng thành phải luôn tự hỏi:

API này sync hay async?
Có timeout không?
Có task ID không?
Polling ra sao?
Retry thế nào?
Failure handling thế nào?

Đó là khác biệt giữa:

viết script demo

và

xây automation chạy production thật.
]]> CCNP Automation dangquangminh https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440371-sync-api-và-async-api Các yếu tố chính khi thực hành DevOps https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440327-các-yếu-tố-chính-khi-thực-hành-devops Mon, 18 May 2026 03:27:46 GMT Continuous Delivery / Continuous Integration (CI/CD) CI/CD hỗ trợ mục tiêu giảm thời gian cập nhật hoặc triển khai phần mềm đồng thời nâng cao chất... Continuous Delivery / Continuous Integration (CI/CD)
CI/CD hỗ trợ mục tiêu giảm thời gian cập nhật hoặc triển khai phần mềm đồng thời nâng cao chất lượng.

Continuous Integration (CI) giúp tăng hiệu quả bằng cách cho phép các thành viên trong nhóm phát triển các module độc lập trước khi tích hợp chúng vào một môi trường build chung.
Continuous Deployment (CD) đảm bảo chất lượng bằng cách kiểm thử các bản build trong môi trường production.

Tự động hóa quy trình (Automating Processes)
Automation giúp giảm lỗi do con người và cải thiện khả năng phản hồi của môi trường phát triển. Các công cụ tự động hóa giúp:

Chuẩn hóa quy trình để dễ dàng tái sử dụng
Giảm chi phí bảo trì, nâng cấp và đầu tư hạ tầng
Rút ngắn vòng đời phát triển phần mềm bằng cách giảm thời gian triển khai
Tăng độ tin cậy và khả năng tái sử dụng của các thành phần hệ thống

Xây dựng văn hóa DevOps
Kết hợp đội ngũ phát triển phần mềm và vận hành IT thành một đội DevOps mạnh mẽ đòi hỏi sự thay đổi về văn hóa tổ chức. Có thể bắt đầu bằng cách:

Tăng cường giao tiếp giữa các nhóm
Triển khai các dự án nhỏ để tạo cơ hội cộng tác
Xác định những nhân sự chủ chốt để phát triển thành DevOps Engineer
Lựa chọn các công cụ dùng chung nhằm cung cấp dữ liệu khách quan

Đo lường DevOps
Các chỉ số KPI giúp đánh giá hiệu quả triển khai DevOps. Một số chỉ số quan trọng gồm:

Tần suất triển khai (Deployment Frequency)
Tỷ lệ lỗi khi thay đổi hệ thống (Change Failure Rate)
Thời gian khôi phục trung bình – MTTR (Mean Time To Recovery)
Lead Time
Khối lượng thay đổi (Change Volume)
Tỷ lệ lỗi lọt ra production (Defect Escape Rate)
Ticket hỗ trợ khách hàng

Sự khác biệt giữa DevOps và Agile
DevOps
DevOps là phương pháp tập trung vào sự tích hợp và cộng tác giữa đội phát triển phần mềm và đội vận hành IT nhằm rút ngắn chu kỳ phát triển và triển khai sản phẩm.
Agile
Agile là phương pháp phát triển phần mềm tập trung vào việc cập nhật và phát triển từng phần nhỏ của phần mềm theo từng giai đoạn liên tục để cải tiến sản phẩm.

Các loại công cụ sử dụng trong DevOps
Build Server
Build Server là một công cụ tự động hóa cho phép mã nguồn trong repository được biên dịch thành chương trình có thể chạy được.
Ví dụ phổ biến:

Jenkins
SonarQube
JFrog Artifactory

Source Code Repository
Source Code Repository là thành phần quan trọng của Continuous Integration, cho phép lập trình viên quản lý nhiều phiên bản mã nguồn mà không ảnh hưởng đến công việc của nhau.
Các công cụ phổ biến:

Git
Bitbucket
Apache Subversion

Configuration Management
Configuration Management giúp duy trì tính nhất quán và chất lượng của hạ tầng CNTT.
Các công cụ phổ biến:

Puppet
Ansible
Chef

Virtual Infrastructure
Virtual Infrastructure là các dịch vụ hạ tầng dựa trên cloud cung cấp Infrastructure hoặc Platform as a Service (PaaS).
Ví dụ:

Amazon Web Services (AWS)
Microsoft Azure

Khi kết hợp với công cụ automation, virtual infrastructure hỗ trợ DevOps bằng cách cho phép quản trị viên tự động kiểm thử mã nguồn mà không cần thao tác thủ công.

Containers
Containers là các thành phần ảo hóa giúp cô lập ứng dụng hoặc workload khỏi hệ điều hành host trong quá trình phát triển.
Các nền tảng phổ biến:

Docker
Kubernetes
CoreOS

]]> CCNP Automation anhnguyxn https://www.forum.vnpro.org/forum/ccnp-enterprise/automation/440327-các-yếu-tố-chính-khi-thực-hành-devops