เครื่องมือรับมือวิกฤตบนลินุกซ์

• หากเริ่มติดตั้งเครื่องมือวินิจฉัยหลังเกิดปัญหาประสิทธิภาพ เวลาอาจหมดไปกับการเตรียมการมากกว่าการกู้คืน ดังนั้นควรใส่ เครื่องมือรับมือวิกฤต ไว้ล่วงหน้าในอิมเมจเซิร์ฟเวอร์ Linux
• รายการที่แนะนำได้แก่ procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool เป็นต้น ซึ่งเป็นแพ็กเกจขั้นต่ำสำหรับตรวจสอบ CPU, ดิสก์, เครือข่าย และการติดตามระดับเคอร์เนล ได้ทันที
• bcc และ bpftrace มีเครื่องมือที่ซ้ำกันหลายตัว แต่ bcc มีตัวเลือก CLI ครบกว่า ส่วน bpftrace แก้ไขหน้างานได้ง่ายกว่า และขณะรันทั้งคู่จะปล่อย BPF bytecode เดียวกัน
• การติดตั้งระหว่างเกิดเหตุขัดข้องอาจทำให้ เสียเวลาไปหลายสิบนาที จากตัวแปรต่าง ๆ เช่น SSH ที่ช้า, การตั้งค่า apt ที่เสีย, repository ถูกบล็อก, firewall, filesystem แบบ immutable, ข้อผิดพลาดด้านสิทธิ์
• ต้นทุนหลักคือพื้นที่ดิสก์และเวลาในการกระจายอิมเมจ แต่แพ็กเกจที่แนะนำส่วนใหญ่มีขนาดเล็ก หากรวมไว้เป็นค่าเริ่มต้นในดิสทริบิวชัน Linux ระดับองค์กร ก็จะเริ่มรับมือปัญหาประสิทธิภาพได้เร็วขึ้น

---

เครื่องมือขั้นต่ำที่ควรมีไว้ก่อนเกิดเหตุ

• เมื่อเกิดปัญหาประสิทธิภาพ เวลาที่ใช้ติดตั้งเครื่องมือที่จำเป็นต่อการวินิจฉัยสาเหตุถือเป็นเวลาที่สูญเสียไป ดังนั้นการติดตั้ง เครื่องมือรับมือวิกฤต เป็นค่าเริ่มต้นบนเซิร์ฟเวอร์ Linux จึงปลอดภัยกว่า
• รายการนี้อ้างอิงจากตาราง “Linux Crisis Tools” ใน Systems Performance 2nd Edition
• เครื่องมือที่แนะนำตามแพ็กเกจของ Ubuntu มีดังนี้
  • procps: ps, vmstat, uptime, top
    • ตรวจสอบสถิติพื้นฐาน
  • util-linux: dmesg, lsblk, lscpu
    • ตรวจสอบ log ของระบบและข้อมูลอุปกรณ์
  • sysstat: iostat, mpstat, pidstat, sar
    • ตรวจสอบสถิติของอุปกรณ์และระบบ
  • iproute2: ip, ss, nstat, tc
    • เครื่องมือเครือข่ายที่แนะนำให้ใช้
  • numactl: numastat
    • ตรวจสอบสถิติ NUMA
  • tcpdump: tcpdump
    • sniff เครือข่าย
  • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
    • ตรวจสอบสถิติของ profiler และ PMU
  • bpfcc-tools หรือ bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile เป็นต้น
    • เครื่องมือ eBPF ที่เตรียมไว้ล่วงหน้า
  • bpftrace: bpftrace, เวอร์ชันพื้นฐานของ opensnoop, execsnoop, runqlat, biosnoop เป็นต้น
    • scripting ด้วย eBPF
  • trace-cmd: trace-cmd
    • Ftrace CLI
  • nicstat: nicstat
    • สถิติอุปกรณ์เครือข่าย
  • ethtool: ethtool
    • ข้อมูลอุปกรณ์เครือข่าย
  • tiptop: tiptop
    • PMU/PMC top
  • cpuid: cpuid
    • รายละเอียด CPU
  • msr-tools: rdmsr, wrmsr
    • ตรวจสอบ CPU เชิงลึก

วิธีมอง bcc และ bpftrace ร่วมกัน

• bcc และ bpftrace มีเครื่องมือซ้ำกันหลายตัว แต่จุดที่เหมาะกับการใช้งานต่างกัน
• เครื่องมือของ bcc มีฟีเจอร์อย่างตัวเลือก CLI มากกว่า จึงเหมาะจะใช้เหมือนเครื่องมือที่ทำเสร็จแล้ว
• เครื่องมือของ bpftrace สามารถ แก้ไขได้ทันที หน้างาน จึงตรวจสอบตามสถานการณ์ได้ง่าย
• ไม่ได้หมายความว่าอย่างใดอย่างหนึ่งเร็วกว่า
  • ทั้งสองเครื่องมือปล่อย BPF bytecode เดียวกัน
  • ขณะรันจึง เร็วเท่ากัน
• bcc กำลังพัฒนาไปในทิศทางย้ายเครื่องมือที่ใช้ Python เป็นฐานไปยัง libbpf C
  • ใช้ CO-RE และ BTF
  • แต่แพ็กเกจยังไม่ได้ถูกปรับทำใหม่
  • ในอนาคต bpfcc-tools ควรถูกแทนที่ด้วยแพ็กเกจ libbpf-tools ที่เล็กกว่าและมีเฉพาะไบนารีของเครื่องมือ

เครื่องมือเพิ่มเติมตามประเภทเซิร์ฟเวอร์

• รายการข้างต้นเป็นเพียง รายการขั้นต่ำ เท่านั้น
• หากเป็นเซิร์ฟเวอร์ที่มี accelerator ก็ควรใส่เครื่องมือสำหรับวิเคราะห์อุปกรณ์นั้นไว้ด้วย
  • เซิร์ฟเวอร์ Intel GPU: intel-gpu-tools
  • เซิร์ฟเวอร์ NVIDIA: nvidia-smi
• เครื่องมือ debugging อย่าง gdb ก็อาจติดตั้งไว้ล่วงหน้าได้ หากต้องการใช้งานทันทีในสถานการณ์วิกฤต
• เครื่องมือวิเคราะห์ที่จำเป็นไม่ได้เปลี่ยนบ่อยนัก ดังนั้นรายการนี้อาจต้องอัปเดตเพียงทุกไม่กี่ปี

ต้นทุนจริงของการติดตั้งเป็นค่าเริ่มต้น

• ข้อเสียที่เห็นชัดเป็นอันดับแรกเมื่อเพิ่มแพ็กเกจคือ การใช้พื้นที่ดิสก์
• ใน cloud instance แม้อิมเมจเซิร์ฟเวอร์พื้นฐานจะใหญ่ขึ้นเพียงไม่กี่ MB ก็อาจทำให้เวลา deploy instance เพิ่มขึ้นเป็นไม่กี่วินาทีหรือเศษเสี้ยววินาที
• แพ็กเกจที่แนะนำส่วนใหญ่มีขนาดเล็ก และ bcc ก็น่าจะเล็กลงอีก ดังนั้นต้นทุนด้านพื้นที่และเวลาจึงไม่ควรสูงมาก
• debuginfo มีขนาดรวมประมาณ 1GB จึงเคยมีความกังวลด้านพื้นที่จริง ๆ ที่ทำให้ไม่รวมไว้เป็นค่าเริ่มต้น

ลำดับเหตุการณ์เมื่อการติดตั้งระหว่างเกิดเหตุถูกขัดขวาง

• หากพยายามติดตั้งเครื่องมือหลังเกิดเหตุขัดข้อง เวลาอาจถูกดูดไปกับการแก้ปัญหาการติดตั้งแทนการวินิจฉัย
• ตัวอย่างลำดับเหตุการณ์มีดังนี้
  • 4:00pm: เว็บไซต์บริษัทล่มหรือช้าจนใช้งานไม่ได้
  • 4:01pm: dashboard monitoring พบว่ากลุ่มเซิร์ฟเวอร์ backend ผิดปกติ และสงสัยว่ามี disk I/O สูง
  • 4:02pm: พยายาม SSH เข้าเซิร์ฟเวอร์ แต่ login ช้ามาก
  • 4:03pm: พยายามรัน iostat -xz 1 แต่ไม่มี iostat และมีข้อความแนะนำให้ติดตั้ง sysstat
  • 4:07pm: การติดตั้งแพ็กเกจล้มเหลวเพราะ resolve repository ไม่ได้ และพบปัญหาการตั้งค่า /etc/apt
  • 4:10pm: ต้องรัน apt-get update ด้วยการตั้งค่าที่แก้แล้ว แต่ช้ามาก
  • 4:13pm: เกิด connection timeout และเริ่มสงสัยปัญหาการเชื่อมต่อ repository หรือปัญหาประสิทธิภาพ
  • 4:17pm: ยืนยันได้ว่าทีม network security บล็อกทราฟฟิกที่ไม่คาดคิดและคำขอ apt outbound ผ่าน HTTP/HTTPS/FTP
  • 4:20pm: หลังปิด firewall แล้ว apt-get update ทำงานได้ แต่การติดตั้งเกิดข้อผิดพลาดเรื่องสิทธิ์
  • 4:24pm: ทีม platform security อธิบายว่าเป็น ระบบ immutable ที่บล็อกการเขียนลง filesystem บางส่วน เช่น พื้นที่ไบนารีที่รันได้
  • 4:27pm: ทีม SRE แจ้งเหตุขัดข้องขนาดใหญ่ ผู้บริหารต้องการอัปเดตสถานะและ ETA การกู้คืน แต่การวินิจฉัยจริงแทบไม่ได้คืบหน้า
  • 4:30pm: พยายามใช้ cat /proc/diskstats เป็นตัวแทน iostat แบบหยาบ ๆ แต่ต้องอ่านเอกสาร Linux และยืนยันได้เพียงข้อเท็จจริงเดิมว่าดิสก์กำลังยุ่ง
  • 4:55pm: อิมเมจเซิร์ฟเวอร์ใหม่ที่มี filesystem เขียนได้ถูกเปิดขึ้น และสามารถติดตั้ง sysstat ได้แล้ว แต่เว็บไซต์กลับมาเพียงเพราะ restart เซิร์ฟเวอร์เท่านั้น สาเหตุยังไม่ได้รับการแก้ไข
  • 12:50am: ตัวอย่างดำเนินต่อไปเป็นสถานการณ์ที่เว็บไซต์ถูกแฮ็กจากผลของการปิด firewall และความปลอดภัยของ filesystem ไว้
• เหตุการณ์ 12:50am ไม่ใช่ประสบการณ์จริง แต่ส่วนที่เหลือเป็นตัวอย่างจากประสบการณ์จริง
• ในที่ทำงานเดิม มีบางครั้งที่ประมาณนาทีที่ 15 “traffic team” จะเริ่ม failover ของ cloud region และเมื่อการติดตั้ง iostat เสร็จ ระบบเป้าหมายก็อาจว่างงานไปแล้ว

เหตุผลที่ควรใส่ไว้ในอิมเมจพื้นฐาน

• สถานการณ์ข้างต้นแสดงให้เห็นว่าการติดตั้งเครื่องมือภายหลังระหว่างเกิด incident ใน production นั้นเปราะบางเพียงใด
• บางบริษัทมีทีม OS ทำ อิมเมจเซิร์ฟเวอร์แบบกำหนดเอง ที่รวมเครื่องมือจำเป็นไว้ใช้อยู่แล้ว
• แต่ก็ยังมีเว็บไซต์จำนวนมากที่รัน Linux เวอร์ชันพื้นฐานตามเดิม และในกรณีเช่นนี้มักจะตระหนักถึงความจำเป็นหลังจากเจอเหตุขัดข้องแล้ว
• หากดิสทริบิวชัน Linux ระดับองค์กรรวมเครื่องมือรับมือวิกฤตเหล่านี้ไว้เป็นค่าเริ่มต้น บริษัททั้งเล็กและใหญ่จะสามารถเริ่มวินิจฉัยได้ทันทีเมื่อเกิดปัญหาประสิทธิภาพ

[GN⁺]

ความคิดเห็นบน Hacker News

• รายการนี้มีประโยชน์ ในสถานการณ์ที่ตัวเซิร์ฟเวอร์เองรวน เช่น แปลความหมาย repository ของ apt ล้มเหลว คลาวด์ มักจะเหมาะมาก
  แทนที่จะเกาะติดพยายามซ่อม ให้ปิดเครื่องหรือถอดออกจากพูลแล้วเปิดเครื่องใหม่ เครื่องใหม่กับแอปก็จะขึ้นมาอย่างสะอาดและเหตุขัดข้องก็จบลง ส่วนเครื่องที่มีปัญหาค่อยแยกไปขุดดูนอก hot path ได้

  • หลังจาก “แก้” ปัญหาแล้ว มักไม่มีใครมีเวลาหรือได้รับอนุญาตให้ขุดดูเครื่องนั้น สุดท้ายเมื่อเวลาผ่านไป วิธี rebuild ใหม่ตั้งแต่ต้น ก็ทำให้ความสามารถในการแก้ปัญหาจริงและความรู้ที่สะสมไว้หายไป
    กลายเป็นเวอร์ชันซอฟต์แวร์ของ “คนที่ทำได้แค่เปลี่ยนอะไหล่” ในโลกกายภาพ
  • “4:10pm ปัญหาประสิทธิภาพ เดิมยังเกิดกับเครื่องใหม่ด้วย”
  • นั่นไม่จำเป็นต้องเป็นข้อดีของคลาวด์อย่างเดียว แต่ใกล้เคียงกับข้อดีของการเดินระบบ เซิร์ฟเวอร์แบบเสมือนที่เปลี่ยนทดแทนได้ (cattle) มากกว่า
  • ถ้าฆ่าเครื่องทิ้ง หลักฐาน ก็อาจหายไปด้วย อาจมี log ทั้งหมดอยู่ข้างนอกก็ได้ แต่โดยปกติมักมีอะไรบางอย่างขาดไป

• ไม่ใช่ทุกเซิร์ฟเวอร์จะถูกทำเป็นคอนเทนเนอร์ แต่จำนวนมากเป็นคอนเทนเนอร์ และมันก็มีความยากของมันเอง
  เครื่องมือดีบักใน Docker image มักถูกตัวสแกนความปลอดภัยอัตโนมัติจับว่าเป็น “เครื่องมือที่ไม่จำเป็นซึ่งช่วยให้ผู้โจมตีสังเกตและแก้ไขพฤติกรรมของระบบได้” บางกรณีก็น่ากังวลจริงอย่าง gdb แต่หลายกรณีก็ไม่ใช่
  ดังนั้นเครื่องมือบางตัวจึงถูกวางไว้ใน volume แยกต่างหาก ถ้าเป็นไปได้ก็เป็น static binary หรือคอมไพล์และติดตั้งโดยใช้ path ที่ mount เป็น installation prefix หากต้องดีบัก ก็ขอให้ทีมปฏิบัติการ mount ชั่วคราวแบบอ่านอย่างเดียวให้
  อีกอย่าง หากเครื่องมือดีบักบางตัวต้องให้เปิดใช้ฟีเจอร์ของ kernel บางอย่าง ก็มักเกิดคำถามและความกังวลอยู่บ่อย ๆ ว่าจะกระทบคอนเทนเนอร์อื่นบนโฮสต์เดียวกันอย่างไร

  • ถ้าผู้โจมตีสามารถรันไฟล์จาก filesystem ได้ และสิ่งที่ขาดไปสำหรับการรันมีแค่ไฟล์นั้นมีอยู่หรือไม่ ก็น่าจะเขียนไฟล์นั้นลงไปเองได้ไม่ใช่หรือ
    ผมนึกสถานการณ์ที่นโยบายนี้มีความหมายไม่ค่อยออก นอกจาก “องค์กรกำลัง ใช้ตัวสแกนความปลอดภัยผิดวิธี”
  • วิธีที่ดีกว่าคือสร้าง image ตัวที่สองซึ่งมี เครื่องมือดีบักและผู้ใช้ root แล้วรันโดยผูกเข้ากับ PID namespace และ network namespace ของคอนเทนเนอร์ production
    ถ้าจะใช้ debugger มักต้องใช้สิทธิ์ SYS_PTRACE, ผู้ใช้ 0, flag อย่าง --privileged หลายอย่าง ดังนั้นการเปิดคอนเทนเนอร์ตัวที่สองมักจะดีกว่า
    วิธีนี้ไม่ต้อง restart คอนเทนเนอร์ production จึงลดโอกาสที่จะสูญเสียหลักฐานสำหรับการ reproduce ด้วย
    แต่ในสถานการณ์ฉุกเฉิน การจำขั้นตอนนี้ไม่ใช่เรื่องง่าย จึงควรลองไว้ล่วงหน้าและเขียนขั้นตอนทีละข้อไว้ใน runbook

• ที่เกี่ยวข้องกัน ตั้งแต่ FreeBSD 5.2 หรือก็คือปี 2004 ระบบ FreeBSD ทุกเครื่องมี /rescue/*
  มี ไบนารีแบบ static link หนึ่งตัวที่รวมเครื่องมือหลักราว 150 ตัวไว้ด้วยกันและ hardlink เป็นชื่อปกติ ขนาดประมาณ 17MB
  https://man.freebsd.org/cgi/man.cgi?rescue
  https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

  • ตลอด 15 ปีไม่เคยต้องใช้มันเลย ช่วง 4–5 ปีหลังนี้ เพื่อสุขภาพจิต ผมพอร์ตสิ่งที่พอทำได้ไปยัง *BSD

• ตอนอยู่ที่ Netflix Brendan กับทีมของเขาช่วยให้มีการติดตั้ง เครื่องมือดีบัก อย่าง bpftrace, bcc, perf ที่ทำงานได้ถูกต้องไว้ทั่วทุกที่
  เครื่องมือพวกนี้ช่วยชีวิตไว้หลายครั้ง

• แปลกใจที่ไม่มี strace อยู่ในรายการนั้น ปกติเป็นหนึ่งในเครื่องมือแรก ๆ ที่หยิบมาใช้
  โดยเฉพาะเมื่อโปรแกรมคืนข้อความผิดพลาดที่ไร้ประโยชน์หรือผิด strace มีประโยชน์มากจริง ๆ

  • strace ใช้เป็นทางเลือกสุดท้ายได้ แต่ทางเลือกที่ปลอดภัยใน production คือ perf trace และเครื่องมือ tracing ด้วย BPF
    https://www.brendangregg.com/blog/2014-05-11/strace-wow-much...
  • fuser กับ lsof ก็มีประโยชน์
    https://man7.org/linux/man-pages/man1/fuser.1.html
    https://en.m.wikipedia.org/wiki/Lsof

• ในการสัมภาษณ์งานสาย SRE มักจะพูดถึงเครื่องมือแบบนี้เสมอ
  ประเด็นหลักไม่ใช่ว่าผู้สมัครจำคำสั่งเฉพาะได้มากแค่ไหน และถ้าแนะนำเครื่องมือใหม่ให้ก็ถือว่าน่าประทับใจ แต่เราดูว่าเขารู้ว่าอะไรทำได้บ้าง มีเครื่องมืออะไรอยู่ และใช้อย่างไร
  สิ่งสำคัญคือความเข้าใจว่าสามารถจับและวิเคราะห์ ทราฟฟิกเครือข่าย, system call, execution profile และตรวจดูสถานะของระบบปฏิบัติการกับฮาร์ดแวร์ได้

• ถ้าในสถานการณ์วิกฤตแบบนี้ติดตั้งเครื่องมือไม่ได้ ก็สามารถใช้ Docker เพื่อรัน utility หลายอย่างได้
  เช่น build คอนเทนเนอร์ในบรรทัดเดียว หรือผูกเข้ากับเครือข่ายของโฮสต์เพื่อรันเครื่องมือแนว netstat หรือ mount /proc แล้วใช้ --privileged, --net host, --pid host เพื่อรัน เครื่องมือระบบ อย่าง iostat, sar, vmstat, mpstat, pidstat
  แน่นอนว่า yum install ดีกว่า แต่ถ้าใช้ Docker ได้และรับมือกับ mapping ที่จำเป็นได้ ก็เป็นทางเลือกหนึ่งได้ ใน setup แบบ rootless หรือ Podman คงไม่น่าจะใช้ได้ดี

  • มีสถานการณ์ที่ apt ดาวน์โหลดและติดตั้งแพ็กเกจไม่ได้ แต่ Docker กลับดึงคอนเทนเนอร์ใหม่มาได้ด้วยหรือ
    อาจเป็นกรณีที่ library ของ apt พังอะไรแบบนั้นหรือเปล่า
  • ถ้าเป็นสถานการณ์ แยกเครือข่าย ก็เป็นข้อยกเว้น ถ้าจะดึง image “Ubuntu” มา ก็ขอให้โชคดี
  • ในบริบทนั้น ผมอยากให้ busybox มีเครื่องมือแบบนี้มากขึ้น
    ถ้ามีไฟล์ขนาดราว 1MB ที่อัปโหลดขึ้นเซิร์ฟเวอร์แล้วรันได้ทันที จะช่วยได้มาก

• ทุกคนได้สิทธิ์ root กันหมดเลยเหรอ ผมจะทำอะไรก็ต้องเปิด ticket ถึงผู้ดูแลระบบ ก่อน

  • ตอนนี้ผมเป็นที่ปรึกษา จึงไปบริษัทใหม่ทุกไม่กี่เดือน มีคนบางกลุ่มที่ต้องรักษาความสัมพันธ์ให้ดีเสมอ
    ควรจำชื่อฝ่ายความปลอดภัย คนใส่แจ็กเก็ตแปลก ๆ ที่ให้เข้าอาคารได้ และเตรียมบัตร Starbucks ไว้ด้วย
    ควรสุภาพกับพนักงานทำความสะอาดและจำชื่อให้ได้ โต๊ะของผมจะสะอาดขึ้น บางครั้งการอยู่ดึกเพื่อทำความรู้จักคนเหล่านี้ก็คุ้มค่า
    สร้างเพื่อนในทีมบัญชีก็ดี ดื่มกาแฟ กินมื้อกลางวัน คุยเรื่องอื่นนอกจากงานและแสดงความสนใจ คนที่เหมาะสมจะบอกคุณเมื่อกำลังจะมีการเลิกจ้างหรือเมื่อเงินบริษัทเริ่มคล่อง
    กับ IT หรือคนที่แจกแล็ปท็อปและจัดการอีเมลก็ต้องทำดีด้วย คุณจะเห็นเองว่าเขาถอดเครื่องมือความปลอดภัยไร้สาระออกจากคอมพิวเตอร์ของคุณได้เร็วแค่ไหน และคุณจะถูกดันขึ้นหน้าแถวอัปเกรดได้แค่ไหน
    สิ่งสำคัญที่สุดคือ ผู้ดูแลระบบ ไม่ใช่แค่เพราะเรื่อง root แต่เพราะผู้ดูแลระบบที่ดีเขียนโค้ดเป็นแต่จะไม่พูดเสียงดัง ผู้ดูแลที่ดีจะบอกได้ว่ามีศพอยู่ในมุมมืดตรงไหน และมันเป็นแค่ตู้เก็บของหนึ่งตู้หรือทั้งสุสาน ถ้าคุณเรียนรู้วิธี build ให้เข้ากับแพลตฟอร์มของพวกเขา คุณจะได้อิสระในการตัดสินใจมากขึ้นมาก ถ้าพวกเขาขออะไร ก็ควรทำให้
  • สมัยก่อนผมทำ IT operations และในที่นี้หมายถึงระบบ, SRE, ความปลอดภัย
    บทความนี้มุ่งไปที่คนที่รันแอปบนโครงสร้างพื้นฐานที่ IT จัดให้ ถ้าต้องมีปฏิสัมพันธ์กันแบบในตัวอย่าง นั่นไม่ใช่ปัญหาทางเทคนิค แต่เป็น ความล้มเหลวระดับองค์กร
    เรามีช่องทางสื่อสารที่ชัดเจนและเชื่อถือได้มาก ผู้คนไม่ได้คุยกันผ่านแชต แต่ทางโทรศัพท์ หรือยุคนี้ก็คงเป็นที่อย่าง Teams โดยให้ dev, ops, security, compliance ทำงานร่วมกัน
    ในทางปฏิบัติ ทุกทีมมีอย่างน้อยคนประสานงาน และโดยปกตินักพัฒนารันแอปบนทรัพยากรที่ทีม operations จัดให้ ฝ่าย compliance อนุมัติ configuration และความน่าเชื่อถือของบริการเป็นงานของทีมพัฒนา ถ้าทำ DevOps ในความหมายนี้ ปัญหามากมายจะหายไป

• ไม่เห็น nmap, netstat, nc เครื่องมือพวกนี้ก็ช่วยชีวิตไว้หลายครั้ง

• ถ้าจะเพิ่มอย่างเดียว ก็คือ nmap
  ปัญหาการเชื่อมต่อเครือข่ายไม่ได้ปรากฏชัดเจนเสมอไปในบางแอป

  • screen, tmux, byobu, pv, rsync และแน่นอน vim ก็จำเป็น