MegaNet Exhibition Planning

CẢI THIỆN CHẤT LƯỢNG
DỊCH VỤ WIFI TẠI TP. HỒ CHÍ MINH
1. Khách hàng hài lòng khi sử dụng dịch vụ
2. Hệ thống hoạt động ổn định
3. Giảm thiểu rủi ro, sai sót do thao tác, vận hành
4. Quản lý kịp thời, nắm bắt vấn đề, xu hướng
Admin Onsite
Quy trình triển khai
Cam kết số lượng kết nối
LoadTest Đúng số lượng người sử dụng
Sóng Test
Công cụ Locust
Tốc độ đường truyền
Tất cả cable qua Switch và Router
Công cụ TestSpeed
Channel khác nhau
Vị trí đứng test khác nhau
Công cụ trên Android / iOS
Công cụ trên Android / iOS
Lưu lại trên Gitlab
System Admin
Wifi Công Cộng
Wifi KH Mua
Server Vật Lý
Server Được Ảo Hóa
Phần mềm giám sát theo thời gian
Giao tiếp giữa Cloud & thiết bị
Thiết bị dự phòng
Thiết bị của MegaNet
Thiết bị của Khách
Mã nguồn mở
Mã nguồn đóng
Kiểm tra mạng
Điều khiển nguồn điện
SSH đến quản trị thiết bị
Cầu nối để Node Exporter và Prometheus giao tiếp
Node Exporter
RAM
CPU
Uptime
Internet Traffic
Bandwidth
AutoSSH
Admin Online
Quy trình vận hành
Tiếp nhận vấn đề của KH
Tiếp nhận vấn đề của Quản Lý
Quy trình khác
Skype
Email
Zalo
Lưu lại trên Gitlab
Khách Hàng
Quy trình phản ảnh chất lượng dịch vụ
Quy trình ngừng cung cấp dịch vụ
Hình ảnh kèm thời gian rõ ràng
Miêu tả sự cố
Lý do (optional)
Các Công Cụ
Grafana - Graphic
Prometheus - Collector metrics
Alert Manger
Slack
Apps Khác
Grafana
Prometheus
Alert Manager
Gitlab
Triển khai thêm
Có sẵn
Admin Sale
Bán cho ai
Bán ở đâu
Yêu cầu của khách
Những điều cần lưu ý
Lưu lại trên Gitlab
ESP8266
Cam kết những gì
QUY TRÌNH CHUNG
MegaNet Portal
UI cho người quản lý
API cho hệ thống tự động deploy
AWX - Controller
Portal - General Management
Quy trình thu hồi
Thu hồi những gì?
Lưu lại trên Gitlab
Chat Group
Private Chat
Push Notification
Mute when doing
Alert when happened
Vấn đề gì?
Đã xử lý ra sao?
Khi nào xử lý xong?
Tiếp Nhận - Phản hồi
Tiếp nhận & Phản hồi
Đã có hướng xử lý
Chưa có hướng xử lý
Xử lý như thế nào?
Khi nào xong?
Khó khăn cần thông cảm (nếu có)
Dự định sẽ làm gì?
Khi nào có quyết định?
===== QUY TRÌNH LÀM VIỆC CỦA CÁC BỘ PHẬN ======
1. SALE ADMIN
[Giai Đoạn Triển Khai]
- Tạo Project [Tên Project] và [Mô Tả] trên Gitlab
- Note lại thông tin trên Gitlab để Team OnSite triển khai chính xác những yêu cầu của Sale
- Assigned lại cho team Onsite đi triển khai
- Theo dỗi quá trình triển khai cho đến khi hoàn tất
[Giai Đoạn Sau Triển Khai - Chăm sóc khách hàng]
- Theo dỗi feedback của KH qua Gitlab feedback từ Team Online
[Yêu cầu trên Gitlab]
- Triển khai cho ai, ở đâu, yêu cầu căn bản, yêu cầu thêm, lưu ý (nếu có).
________________________________________
2. ADMIN ONSITE
- Thực hiện các yêu cầu đặc thù của Sale ghi chú bên Project Gitlab
- Thực hiện việc triển khai cơ bản kèm với báo cáo cuối cùng
- Những khó khăn (note vào Gitlab Project).
- Những kinh nghiệm xử lý (Note vào Gitlab Wiki chung của Công ty)
[Yêu cầu trên Gitlab]
* Triển Khai
- Những thiết bị cần để triển khai
- Những gì đã triển khai tại địa điểm triển khai (Test Speed từng cable, test sóng tất cả các nơi, test số lượng người kết nối
* Thu Hồi
- Thu hồi những thiết bị nào
________________________________________
3. ADMIN ONLINE
[Xử lý chủ động từ hệ thống đưa lên]
- Kiểm tra tình trạng các thiết bị wifi tại các nơi trên (Slack, Prometheus).
- Thứ tự ưu tiên cho các địa điểm phát Wifi
1. Sân Bay
2. Mall
3. Quán Coffee
4. Wifi Công Cộng khác
- Tiếp nhận vấn đề:
+ Từ khách:
* Kiểm tra Grafana tình hình của thiết bị tại các thời gian khác nhau của quá khứ
* Kiểm tra bằng cách SSH trực tiếp vào
* Reset thiết bị bằng ESP8266 dự phòng
* Dùng Wifi Exporter để xem nhà cung cấp mạng có ổn định không qua biểu đồ của MQTT ping đến ESP8266
=> Xác định vấn đề (Online xử lý - Nhà cung cấp như Viettel, FPT, VNPT xử lý - Onsite xử lý - KH tự xử lý).
[Xử lý bị động từ khách hàng đưa lên]
Nếu là:
- Email: Hướng dẫn khách gửi email và CC các bộ phận liên quan đến vấn đề. Ví dụ như mua hàng, mua thiết bị thì CC (sales@meganet.com.vn). Nếu vấn đề về kỹ thuật (tech@meganet.com.vn)
- Zalo: Tạo group chat và add các người liên quan vào. Ví dụ Sale thì add nhân viên Sale vào. Kỹ thuật thì có thể add OnSite và System vào
- Nếu là vấn đề kỹ thuật thì xử lý như [Xử lý chủ động từ hệ thống đưa lên]
- Nếu là vấn đề về Sale thì giao cho Sale Admin thực hiện ở (1).
[Yêu cầu trên Gitlab]
- Xử lý cho ai
- Xử lý vấn đề gì
- Đã xử lý bằng các công cụ nào
- Cuối cùng tình trạng của trường hợp này thế nào
- Thời gian kết thúc (cụ thể nếu có thể xác định được bằng cách hỏi hoặc dự đoán)
- Những khó khăn (note vào Gitlab Project).
- Những kinh nghiệm xử lý (Note vào Gitlab Wiki chung của Công ty)
Các thiết bị được triển khai lên
Lưu lại trên Gitlab
===== QUY TRÌNH LÀM VIỆC CỦA CÁC BỘ PHẬN ======
4. KHÁCH HÀNG
[Yêu cầu khách hàng phải làm theo]
- Đề xuất hoặc góp ý hoặc báo cáo vấn đề qua các kênh thông tin liên lạc Meganet đang hỗ trợ như Zalo, Email, Skype, Điện thoại v.v...
- Hình ảnh, thời gian để đối chiếu với phần mềm giám sát trên hệ thống, SSH vào để có thông tin người khác kiểm tra.
5. SYSTEM ADMIN
[ Công việc thường ngày]
- Xử lý các vấn đề như Online Admin
- Xem xét các vấn đề được Online Admin Team giải quyết trên Gitlab để cải thiện chất lượng làm việc (ít tốn thời gian hơn, hiệu quả hơn)
- Xem xét các vấn đề được Onsite Admin Team giải quyết trên Gitlab để cải thiện chất lượng làm việc (ít tốn thời gian hơn, hiệu quả hơn)
- Tổng hợp các ý kiến của Online Admin và Onsite Admin để nâng cấp, chỉnh sửa quy trình thực hiện.
- Xử lý các yêu cầu từ cấp quản lý đưa ra.
[ Các vấn đề phát sinh]
- Hệ thống phát sinh những vấn đề như nâng cấp, lỗi v.v...
- Viết hướng dẫn / trainning sử dụng các công cụ hiện ở công ty cho nhân sự mới
[ Yêu cầu trên Gitlab ]
- Xử lý vấn đề gì
- Tiếp nhận vấn đề từ bộ phận nào
- Phát sinh vấn đề (nếu có)
- Đã xử lý vấn đề bằng cách nào
- Cuối cùng tình trạng của trường hợp này thế nào
- Thời gian kết thúc (cụ thể nếu có thể xác định được bằng cách hỏi hoặc dự đoán)
- Những khó khăn (note vào Gitlab Project).
- Những kinh nghiệm xử lý (Note vào Gitlab Wiki chung của Công ty)
Proof of Concept (PoC)
* Triển khai dự án mới demo ở góc nhìn của vị trí Sale
Sale Admin note lại các thông tin khách hàng yêu cầu.
=> Note lại thông tin này trên Gitlab và assign lại cho người có thẩm quyền quyết định sẽ chọn phương pháp nào để triển khai đạt được yêu cầu này của KH.
Trong khi chờ đợi người có thẩm quyền chọn phương pháp, Sale có thể đi làm các việc khác mà không cần vào Gitlab nhìn xem có cập nhật gì chưa. Vì khi cập nhật Slack sẽ báo là người có thẩm quyền đã xử lý xong chưa.
Vậy là sau khi Slack báo Người có thẩm quyền đã xử lý xong và chuyển lại cho bạn. Bạn có thể xem xét lại, nếu không có vấn đề gì thì sẽ assign lại vấn đề này cho Team Onsite khi triển khai như kế hoạch trên Gitlab.
Sale Admin không cần phải luôn vào Gitlab để xem tình hình triển khai đến đâu. Vì khi có cập nhật gì mới thì Slack sẽ chủ động báo lên khi Onsite có một hành động, hoặc một sự kiện trên Gitlab.
Vậy thì Project có khi sẽ được triển khai, hoặc không được triển khai, hoặc có vấn đề trong quá trình triển khai đều có thể nắm bắt dễ dàng do Slack báo. Sale không cần phải lúc nào cũng vào Gitlab để check. Có thời gian.
Vậy Sale, Người quyết định triển khai và Onsite Team hỗ trợ nhau đi đến hết dự án mà cấp quản lý của 3 Team vẫn có thể nắm bắt thông tin của 3 team một cách dễ dàng cho đến lúc hoàn thành.
Proof of Concept (PoC)
* Online Admin tiếp nhận một vấn đề từ khách hàng
- Khách hàng gọi điện thoại đến Hotline của công ty và phàn nàn rằng Wifi không sử dụng được. (Rất là chung chung như thế).
Online Admin cần phải nhìn vào QUY TRÌNH LÀM VIỆC CỦA CÁC BỘ PHẬN ở phần (4. KHÁCH HÀNG).
Và yêu cầu khách:
1. Có thể trao đỗi qua các kênh MegaNet hỗ trợ giao tiếp
2. Cung cấp bằng chứng wifi xài không được (hình ảnh và thời gian rõ ràng).
Hẹn KH lại sau khoảng 15 phút sẽ báo lại khách.
Sau khi note lại trên Gitlab tình huống của khách và xem xét vấn đề.
=> Vấn đề này Online Admin này có thể xử lý nhanh: Xử lý luôn rồi báo lại KH sớm
=> Vấn đề xử lý lâu
Báo lại KH là sẽ kiểm tra online và sẽ tốn khoản 15-30 phút làm việc.
Online Admin đi kiểm tra bằng các công cụ:
- Grafana biểu đồ RAM, CPU, Traffic v.v...
- SSH vào kiểm tra vấn đề
- Reset thiết bị bằng thiết bị dự phòng (esp8266).
=> Giải quyết được thì báo lại KH & note lại đã xử lý bằng cách nào, bị vấn đề gì.
- Trong trường hợp không xử lý được: Chuyển lên cho bộ phận quản trị hệ thống bằng cách vào Gitlab và assign cho bộ phận System Admin
=> Assign lại cho System Admin kèm theo lý do tại sao lại Assign cho System Admin.
Trong trường hợp có thể xác định là vấn đề do hạ tầng trên cơ sỡ thông tin của các công cụ cung cấp.
=> Assign lại cho Onsite Team kèm theo các thông tin thu thập được trên các công cụ giám sát của công ty (bằng chứng).
Ghi chú:
1. Nếu có sự việc không có trong quy trình. Vui lòng báo lại cho người xây dựng quy trình bằng cách Assign cho người quản lý quy trình kèm theo mô tả vấn đề.
2. Nếu mọi thứ có thể hoạt động tốt, mà không làm theo thì phải có phương pháp ép buộc.
3. Nếu mọi thứ hoạt động chưa tốt, có thể không cần làm. Team quản lý quy trình chịu trách nhiệm và đưa ra phương pháp xử lý để tránh tổn thất hoặc chậm trễ công việc.
4. Quy trình luôn được cập nhật bởi mọi người và xu thế, xu hướng trong từng thời điểm.
5. Trong biểu đồ này: Các dấu mũi tên chỉ sự tương tác qua lại giữa các bộ phận thông qua Gitlab.
Gitlab sẽ là nơi lưu trữ toàn bộ quá trình, hành động của tất cả các cá nhân, công nghệ theo thời gian. Và sẽ luôn được kế thừa để phát triển.
Thiết bị dự phòng (ESP8266)
Kiểm tra kết nối với internet
Bật tắt nguồn điện
15