Animated Architecture Patterns

Eliminating Toil

หางาน operation ที่ต้องทำมือซ้ำ ๆ และโตตามระบบ แล้ววัดมัน ตั้งเพดานให้มัน และทำ automation กำจัดมันทิ้ง

หรือที่เรียกกันว่า Toil reduction, Toil management

Interrupts what lands on the SRE group Tickets· OPS queueDB users, certs, disksPages· on-callconsumer stuck, disk full Chat· #sre-help“can you get me the logs?” Each one takes minutes.Together they fill 62% ofthe week, and every newservice adds more. For two weeks the group logsevery task with its time,interrupts, meetings andproject work alike. Fewer interrupts: logs andDB users are self-service,certificates renew on theirown, the consumer is quiet. ✗ Chat requests nobody logsare hidden toil: measureevery channel, every quarter. SRE group’s week 4 engineers × 40 h = 160 h 50% cap planned: 88% engineering toil 62%engineering 26% toil 37%engineering 51% toil 28%engineering 60% toil overhead: meetings, planning engineering over the cap under the cap Toil grows with servicesSRE hours a week as Acme adds services50%160 h20 services50 h40 · now99 h60 · next?≈ 149 heach new service adds ≈ 2.5 h a weekof certificates, users, disks, logstoil grows O(n) with services;engineering is done once Platform roadmapKubernetes upgrademulti-zone Postgresself-service namespaces planned for this quarterslippedslippedslippedengineering: 26% of the weekthe plan was 88%no project work: careers stalland people burn out Two-week time logevery task with its time, then sortedrenew checkout TLS cert45 mintoilDB user for search15 mintoildesign review: order events2 hengineeringteam meeting1 hoverheadlogs for checkout (chat)30 mintoilrestart orders-consumer3 htoilIs it toil?Google SRE book, ch. 5manualrepetitiveautomatabletacticalno lasting valuegrows with servicemore ticks → toilmeeting: overheadTwo weeks: toil 62% · overhead 12% · engineering 26% Toil, measured each quartershare of the SRE group’s time50% cap62%37%28%baseline+1 quarter+2 quartersnext: disk resizing, the long tail two quarters laterdonedoneon trackengineering: 60% of the weekthe roadmap moves again Worth automating?hours saved a year vs. time to buildLog access✓ pays back2,000 h a year · 3 weeks to buildDB users module✓ pays back100 h a year · 3 days to buildQuarterly audit export✗ skip it2 h a year · 3 days to build12 years to pay back: checklistCount the upkeep too: an owner,alerts, upgrades, docs. Developer logs by hand 40 h/wk −40 h/wk copied from pods by handkubectl logs, pasted in chat ≈ 80 requests a week × 30 min ✓ central log access devs search their own logsself-service, read-only Order consumer by hand 9 h/wk −9 h/wk restarted by hand when stuckthen the stuck orders re-driven 3 pages a week × ≈ 3 h ✓ fixed at the root idempotent processingliveness probe as a backstop ✗ a cron restart every 30 minautomates what shouldn’t exist TLS certificates by hand 3 h/wk −3 h/wk renewed by handCSR, issue, upload, reload ≈ 4 a week × 45 min ✓ cert-manager renews at 2/3 of the lifetimeday 60 of a 90-day cert ✗ if it fails, who still knowshow certificates get issued? Database users by hand 2 h/wk −2 h/wk created from ticketsOPS ticket, then psql by hand ≈ 35 a month × 15 min ✓ self-service module reviewed PR, Terraform appliesteams add their own users ✗ nobody owns the module: itbreaks, and the tickets return logs for checkout? orders-consumer stuck cert expires in 7 d DB user for search disk 90%: pg-orders

ขั้นที่ 1 · งานแทรกกินทั้งสัปดาห์ กลุ่ม SRE ของ Acme (วิศวกร 4 คนที่ดูแล platform และช่วยทีม product) วางแผนสัปดาห์ตาม roadmap ของ platform แล้วงานแทรกก็เข้ามา: ticket ขอ database user และขอต่ออายุ certificate, page เรื่อง order consumer ค้างและ disk เต็ม, ข้อความใน chat ที่มาขอ log ตัวงานแต่ละอย่างใช้เวลาไม่กี่นาทีหรือไม่กี่ชั่วโมง แต่รวมกันแล้วกินไป 62% ของสัปดาห์ 160 ชั่วโมง และทุก service ใหม่ก็เพิ่มงานอีกราว 2.5 ชั่วโมง ผลคือ roadmap เลื่อนออกไป และคนก็หมดไฟ (ตัวเลขของ Acme เป็นของตัวอย่างนี้เอง)

ขั้นที่ 2 · ใช่ toil ไหม วัดดูก่อน ตลอดสองสัปดาห์ ทุกคนจดทุกงานที่ทำพร้อมเวลาที่ใช้ แล้วเอาบันทึกนั้นมาแยกด้วยเกณฑ์จากบท Eliminating Toil ในหนังสือ SRE ของ Google: toil คืองานที่ต้องทำมือ ซ้ำ ๆ ทำ automation ได้ เป็นงานเฉพาะหน้า ไม่มีคุณค่าระยะยาว และโตตาม service แล้วการต่ออายุ certificate หรือการสร้าง database user ก็ตรงทุกข้อ ส่วน design review คืองาน engineering และประชุมทีมคือ overhead ที่ก็ไม่ใช่ toil เหมือนกัน ผลที่ได้คือ toil 62%, overhead 12%, engineering 26% พร้อมจำนวนชั่วโมงที่ toil แต่ละแบบกินไป

ขั้นที่ 3 · กำจัดก้อนใหญ่สุดก่อน กลุ่มจัดอันดับ toil ตามชั่วโมงที่จะประหยัดได้ แล้วกำจัดก้อนใหญ่สุดก่อน: developer ได้สิทธิ์อ่าน log กลางเอง (40 h ต่อสัปดาห์), order consumer ได้การแก้จริง คือประมวลผลแบบ idempotent โดยมี liveness probe เป็นตัวกันอีกชั้น (9 h), cert-manager ต่ออายุ certificate ให้ (3 h) และ Terraform module ก็เปลี่ยนการขอ database user ให้เป็น pull request ที่ผ่าน review (2 h) พอวัดทุกไตรมาส toil ก็ลดจาก 62% เป็น 37% แล้วเป็น 28% ต่ำกว่าเพดาน 50% ที่ Google ตั้งไว้ให้งาน operation ของ SRE แล้ว roadmap ก็กลับมาเดินอีกครั้ง

ขั้นที่ 4 · กับดักและข้อจำกัด cron job ที่ restart consumer ทุก 30 นาทีคือการทำ automation ให้ process ที่ไม่ควรมีอยู่ตั้งแต่แรก ส่วน module ที่ไม่มีใครเป็นเจ้าของก็จะพัง แล้ว ticket ก็กลับมา งาน export 30 นาทีที่ทำปีละสี่ครั้งไม่คุ้มกับการลงแรงทำ automation สามวัน ส่วน request ที่ไม่เคยถูกจดลงบันทึกก็ซ่อนอยู่ต่อไป และวันที่ cert-manager พัง ก็ยังต้องมีคนที่รู้ว่า certificate ออกกันยัง⁠ไง

ปัญหา

กลุ่ม SRE ของ Acme Shop มีวิศวกรสี่คน ดูแล platform ที่ใช้ร่วมกัน (cluster ของ Kubernetes, CI/CD และ observability stack) และช่วยทีม product ด้วย สัปดาห์ของพวกเขาควรเป็นของ roadmap ของ platform แต่กลับหมดไปกับงานแทรก: ticket ขอ database user หรือเตือนว่า certificate ใกล้หมดอายุ, page ตอน order consumer ค้างหรือ disk เต็ม, ข้อความใน chat จาก developer ที่ต้องการ log ของ production แต่ดูเองไม่ได้ แต่ละ request เล็กนิดเดียว และแต่ละอันก็สมเหตุสมผล บันทึกเวลาสองสัปดาห์บอกว่าสัปดาห์หมดไปกับอะไรจริง ๆ: 62% ไปกับงานแบบนี้ 12% ไปกับการประชุมและวางแผน และ 26% ไปกับงาน engineering (ตัวเลขของ Acme เป็นของตัวอย่างนี้เอง ไม่ใช่ผลงานวิจัย)

แนวโน้มแย่กว่าตัวเลข ทุก service ใหม่พา certificate, database user, disk และ request ขอ log เพิ่มเข้ามา ชั่วโมงที่ใช้เลยโตตามจำนวน service: ที่ Acme คือราว 2.5 ชั่วโมงต่อสัปดาห์ต่อ service ใหม่หนึ่งตัว กลุ่มที่ทำงานพวกนี้ด้วยมือต้องโตตามระบบไปด้วย ไม่อย่างนั้นงาน project ก็หยุดนิ่ง อย่างที่ roadmap เป็นอยู่ตอนนี้ และคนก็หมดไฟ บางส่วนโตขึ้นเองแม้ไม่มี service ใหม่: ตาม CA/Browser Forum ballot SC081v3 ตั้งแต่ 15 มีนาคม 2026 certificate TLS สาธารณะมีอายุได้ไม่เกิน 200 วัน ตั้งแต่มีนาคม 2027 เหลือ 100 วัน และตั้งแต่มีนาคม 2029 เหลือ 47 วัน ทุก certificate ที่ต่ออายุด้วยมือเลยวนกลับมาถี่ขึ้นเรื่อย ๆ

ทำงานยัง⁠ไง

Toil คือชื่อที่หนังสือ Site Reliability Engineering ของ Google (O'Reilly, 2016) ใช้เรียกงาน operation แบบหนึ่ง ในบทที่ 5 Eliminating Toil ที่ Vivek Rau เขียน มันคืองานที่ผูกอยู่กับการรัน service บน production และมีลักษณะแบบนี้:

  • ทำมือ (manual): คนเป็นคนรันคำสั่งหรือ script เอง
  • ซ้ำ ๆ (repetitive): งานเดิมวนกลับมาครั้งแล้วครั้งเล่า
  • ทำ automation ได้ (automatable): เครื่องทำได้ดีพอ ๆ กัน หรือออกแบบระบบให้ไม่ต้องทำงานนี้เลยก็ได้
  • เฉพาะหน้า (tactical): มาจากงานแทรกและเป็นการตามแก้ ไม่ได้วางแผนไว้
  • ไม่มีคุณค่าระยะยาว (without enduring value): ทำเสร็จแล้ว service ก็ไม่ได้ดีขึ้นกว่าก่อนทำ
  • O(n) ตามการโตของ service: โตแบบเส้นตรงตามขนาดของ service, traffic หรือจำนวน user

งานหนึ่งไม่ต้องมีครบทั้งหกข้อ แต่ยิ่งมีมาก ก็ยิ่งน่าจะเป็น toil บทนี้บอกชัดพอ ๆ กันว่าอะไรไม่ใช่ toil อย่างแรกคือ overhead เช่น ประชุมทีม การตั้งเป้าหมาย และงานเอกสาร HR ไม่ได้ผูกกับการรัน production เลยไม่ใช่ toil งานน่าเบื่อที่ทิ้งการปรับปรุงที่อยู่ยาวไว้ เช่น การเก็บกวาด config ของ alert ทั้งหมดของ service หนึ่ง ก็ไม่ใช่ toil เหมือนกัน และ toil ก็ไม่ใช่แค่งานที่ใครสักคนไม่ชอบ: งาน routine ที่คาดเดาได้นิดหน่อยไม่เป็นไร ทำแล้วอาจรู้สึกดีด้วยซ้ำ ปัญหาอยู่ที่ปริมาณ ถ้ามี toil มากเกินไป career ก็หยุดเดินและขวัญกำลังใจก็ตก แล้วทีมที่คอยรับมันไว้เรื่อย ๆ ก็สอนส่วนอื่นขององค์กรให้ส่งมาเพิ่มอีก

งาน engineering คือสิ่งตรงข้าม: เป็นงานที่ต้องใช้วิจารณญาณ และทำให้ service ดีขึ้นแบบถาวร ประเด็นของบทนี้คือ service ที่รันดีโตขึ้นได้ระดับสิบเท่า โดยใช้แรงแค่ครั้งเดียวตอนเพิ่ม resource ส่วน toil ตามนิยามแล้วโตตาม service แต่งาน engineering ไม่ต้องโตตามไปด้วย

เพดาน Google จำกัดงาน operation ไว้ไม่เกิน 50% ของเวลา SRE เพื่อให้อย่างน้อยครึ่งหนึ่งไปอยู่ที่ engineering project ที่ลด toil ในอนาคตหรือเพิ่ม feature บทนำของหนังสือที่ Benjamin Treynor Sloss เขียน อธิบายว่ามันคือเพดานของงาน "ops" ทั้งหมด (ticket, on-call, งานทำมือ) ส่วนบทที่ 5 บอกว่าเป็นเป้าของ SRE แต่ละคน โดยเฉลี่ยในช่วงไม่กี่ไตรมาสหรือหนึ่งปี เพราะ toil มาเป็นช่วง ๆ ทีมที่อยู่เกินเพดานต่อเนื่องจะเปลี่ยนวิธีทำงาน เช่น ส่งงาน operation บางส่วนคืนให้ทีมพัฒนา ผล survey รายไตรมาสของ Google พบว่าโดยเฉลี่ย SRE ใช้เวลาราว 33% ไปกับ toil โดยต้นเหตุอันดับหนึ่งคืองานแทรก ตามด้วยการรับเรื่องตอน on-call และการ release ส่วน The Site Reliability Workbook (O'Reilly, 2018) เสริมไว้ในบท Eliminating Toil ของตัวเอง (บทที่ 6) ว่าลิมิต 50% ครอบคลุมงาน operation ทั้งสองแบบ คือทั้งที่เป็น toil และไม่ใช่ toil และองค์กรอื่นอาจต้องใช้ตัวเลขอื่น สิ่งที่สำคัญคือต้องมีขอบบน และวัดเทียบกับมัน

วัดผล ตัว workbook ขอให้ใช้ข้อมูล ไม่ใช่ความรู้สึก คนที่ทำงานนั้นเป็นคนระบุว่าอะไรคือ toil เลือกหน่วยวัดที่เป็นกลาง (ชั่วโมง, ticket, การเปลี่ยนแปลงที่ทำมือ) แล้วติดตามมันทั้งก่อน ระหว่าง และหลังแต่ละ project ที่ลด toil โดยใช้ tool หรือ script เพื่อให้การวัดไม่กลายเป็น toil ไปอีกตัว ทีม SRE ของ Google ติดตาม toil ใน bug tracker และจัดอันดับตามต้นทุนของการแก้เทียบกับเวลาที่ประหยัดได้ ก่อนเริ่ม project ให้เช็กว่าเวลาที่ประหยัดได้อย่างน้อยต้องได้สัดส่วนกับเวลาที่ใช้สร้างและดูแลการแก้นั้นต่อไป ส่วนประโยชน์ทางอ้อม เช่น ขวัญกำลังใจดีขึ้น context switching น้อยลง และ outage จาก human error น้อยลง ก็ทำให้ project ที่ดูไม่คุ้มเมื่อคิดแค่ชั่วโมงกลายเป็นเรื่องที่ควรทำได้

กำจัดมัน กลยุทธ์จัดการ toil ใน workbook มีอย่างเช่น:

  • ปฏิเสธมัน ตัว workbook แนะนำให้คิดถึงข้อนี้ก่อน: ชั่งต้นทุนของการทำงานนั้นกับต้นทุนของการไม่ทำ แล้วบางทีคำตอบก็คือเลิกทำ ส่วนงานที่ทิ้งไม่ได้ก็มักรวบทำเป็นชุดได้ เปลี่ยนงานแทรกหลาย ๆ ครั้งให้เป็นงานที่วางแผนไว้ครั้งเดียว
  • แก้ที่ระบบจนไม่ต้องมีงานนี้ ตัว workbook เรียกการกำจัด toil ที่ต้นทางว่าเป็นกลยุทธ์ที่ดีที่สุด: แก้ที่สาเหตุ ไม่ใช่แก้ที่อาการ และทำงานกับ developer ให้ software ดูแลง่ายขึ้น
  • ใช้ SLO ตัดสินว่างาน operation ไหนปล่อยไว้ไม่ทำได้ ตราบที่ error budget ยังเอื้อ
  • เริ่มจาก interface ที่มีคนอยู่ข้างหลัง แล้วค่อยไปเป็น self-service ขั้นแรก request form แบบมีโครงสร้างที่ยังมีคนจัดการอยู่ ช่วยให้ request เป็นแบบเดียวกัน จากนั้น form, script, API หรือ pull request ที่มีเอกสารบอกขั้นตอน ก็ให้คนที่ขอทำเองได้
  • ทำ automation กับส่วนที่เหลือ: เริ่มจากเล็ก ๆ ทำระบบให้เหมือนกัน เพื่อให้ automation ตัวเดียวครอบคลุมได้หลายระบบ และใส่ safety check ไว้ในทุกอย่างที่ถือสิทธิ์ admin

บทที่ 7 ของหนังสือ SRE คือ The Evolution of Automation at Google (Niall Murphy กับ John Looney และ Michael Kacirek) อธิบายว่าทำไม automation ถึงมีค่ามากกว่าชั่วโมงที่มันประหยัดได้: มันทำได้สม่ำเสมอ มันกลายเป็น platform ที่คนอื่นสร้างต่อได้ และมันซ่อมและลงมือได้เร็วกว่าคน บทนี้ยังบอกด้วยว่า สิ่งที่ดีกว่าทั้งการทำมือและ automation คือระบบที่ออกแบบมาจนไม่ต้องใช้ทั้งสองอย่าง

ลงมือทำจริงยัง⁠ไง

  1. จดงานสองสัปดาห์ ทุกคนบันทึกทุกงานพร้อมเวลาที่ใช้และที่มา: ticket, page, chat, ประชุม หรือ project แค่ spreadsheet หรือ label บน ticket ก็พอ แต่ต้องรวมช่องทางที่ไม่ทิ้ง ticket ไว้ด้วย โดยเฉพาะ chat
  2. แยกบันทึก เป็น toil, overhead และ engineering ด้วยลักษณะทั้งหกข้อ แล้วตกลงเรื่องกรณีก้ำกึ่งกันเป็นทีม
  3. จัดอันดับ toil ตามชั่วโมง แล้วเลือกวิธีแก้ให้แต่ละแบบ: ปฏิเสธ แก้ที่สาเหตุ ทำเป็น self-service หรือทำ automation ส่วน toil สี่อันดับแรกของ Acme อยู่ในตารางด้านล่าง
  4. เช็กความคุ้ม การเปิดสิทธิ์ดู log ประหยัดได้ราว 2,000 ชั่วโมงต่อปีด้วยงานราวสามสัปดาห์ ส่วน module สำหรับ database user ประหยัดได้ราว 100 ชั่วโมงต่อปีด้วยงานสามวัน นับค่าดูแลด้วย: automation ทุกตัวต้องมีเจ้าของ มี alert มีการ upgrade และมีเอกสาร
  5. ดูแลแต่ละการแก้เหมือน product ที่มีเจ้าของ cert-manager เป็นของทีม platform โดยมี alert สำหรับ certificate ไหนก็ตามที่ใกล้หมดอายุ เผื่อการต่ออายุพลาด ส่วน Terraform module มีคน maintain และอยู่รวมกับโค้ดส่วนอื่นของ platform
  6. วัดใหม่ทุกไตรมาส เทียบกับเพดาน แล้วใส่งานถัดไปลงรายการ: ในที่นี้คือการขยาย disk และงานเล็ก ๆ จำนวนมากที่เหลืออยู่

toil สี่แบบที่ใหญ่ที่สุดของ Acme และสิ่งที่กำจัดมันไป:

Toil ที่วัดได้ อะไรกำจัดมันไป ประเภทของการแก้ ประหยัดได้ต่อสัปดาห์
ก๊อป log ให้ developer ≈ 80 request ต่อสัปดาห์ × 30 min สิทธิ์อ่านอย่างเดียวใน log store กลาง จำกัดขอบเขตตาม service ของแต่ละทีม Self-service 40 h
restart order consumer ที่ค้าง 3 page ต่อสัปดาห์ × ≈ 3 h ประมวลผลแบบ idempotent ทำให้ message ที่ถูกส่งซ้ำไม่ทำให้มันค้างอีก โดยมี liveness probe เป็นตัวกันอีกชั้น แก้ที่สาเหตุ 9 h
ต่ออายุ certificate TLS ≈ 4 ต่อสัปดาห์ × 45 min cert-manager ออกและต่ออายุให้ ทำ automation 3 h
สร้าง database user ≈ 35 ต่อเดือน × 15 min Terraform module โดยทีม product เพิ่ม user ผ่าน pull request ที่ผ่าน review Self-service 2 h
รวม 54 จาก 99 h

กลุ่มเปิดสิทธิ์ดู log ในไตรมาสแรก และทำอีกสามอย่างในไตรมาสที่สอง แล้ว toil ก็ลดจาก 62% ของสัปดาห์เป็น 37% และต่อมาเป็น 28% รายละเอียดบางส่วน:

  • cert-manager ต่ออายุ certificate ตอนผ่านไปสองในสามของอายุโดย default (วันที่ 60 ของ certificate อายุ 90 วัน) แล้ว spec.renewBefore หรือ spec.renewBeforePercentage ก็ใช้เลื่อนจุดนั้นได้ มันใช้กับ ACME issuer อย่าง Let's Encrypt ได้ และใช้กับ certificate authority ภายในได้ด้วย
  • liveness probe ทำให้ kubelet restart container ที่ตรวจไม่ผ่านซ้ำ ๆ เอกสารของ Kubernetes แนะนำให้ใช้กับ deadlock คือตอนที่ process ยังรันอยู่แต่ไม่คืบหน้า และเตือนว่า probe ที่จูนไม่ดีจะ restart container ตอนโหลดหนักจนทำให้แย่ลง มันคือตาข่ายกันตก ส่วนการแก้จริงคือ consumer แบบ idempotent ที่รู้ว่า message ที่ส่งมาซ้ำถูกทำไปแล้ว
  • module สำหรับ database user ใช้ community provider ของ PostgreSQL สำหรับ Terraform ได้ (postgresql_role และ postgresql_grant) อย่าให้ password ไปอยู่ใน Terraform state เช่น ใช้ attribute password แบบ write-only ของ provider และให้ review ของ pull request ตรวจว่าใครได้ grant อะไรบ้าง
  • การเปิดสิทธิ์ดู log ต้องมี store ที่จำกัดสิทธิ์ตามทีมได้ และต้องกันข้อมูลส่วนบุคคลออกจาก log หรือ mask มันไว้ ก่อนที่ developer จะค้นได้

อยู่ตรงไหนใน solution

  • SLOs & Error Budgets: SLO บอกทีมว่างาน operation ไหนรอได้ และการ page ตาม burn ของ error budget แทนที่จะ page ทุกครั้งที่ระบบสะดุดนิดเดียว ก็กำจัด toil ของ on-call ไปได้ทั้งกลุ่ม
  • Idempotent Consumer และ Health Endpoint Monitoring: การแก้ที่ต้นเหตุ และตาข่ายกันตก สำหรับ order consumer ที่ค้าง
  • Centralized Logging: store เดียวที่ค้นได้และให้สิทธิ์ตามทีม เปลี่ยน request ขอ log ให้เป็น self-service
  • GitOps, Immutable Infrastructure และ Infrastructure as Code: การเปลี่ยนแปลงไปผ่าน pull request ที่ผ่าน review และการ rebuild แทนที่จะพิมพ์คำสั่งบน server ทำให้ toil หายไปทั้งหมวด และยังทิ้ง audit trail ไว้ด้วย
  • You Build It, You Run It ตัดสินว่าใครแบกงาน operation ขณะที่หน้านี้พูดถึงการทำให้งานนั้นเล็กลง ไม่ว่าใครจะเป็นคนแบก ถ้าทีม SRE อยู่เกินเพดานต่อเนื่อง การส่งงาน operation บางส่วนคืนให้ developer ก็เป็นหนึ่งในคันโยกที่หนังสือให้ไว้
  • Golden Paths และ Platform as a Product: self-service ในระดับทั้ง platform ทำให้ service ใหม่แต่ละตัวไม่พา ticket ใหม่มาด้วย
  • The Three Ways: เวลาที่ Third Way กันไว้สำหรับปรับปรุงงานประจำวัน คือที่ที่การลด toil เกิดขึ้น
  • Incident Management ดูแลด้านเร่งด่วนของงาน operation ส่วน page ที่ยังกลับมาเรื่อย ๆ หลัง incident จบแล้ว คือ toil ที่ต้องกำจัด

ใช้ตอนไหนดี

  • คุ้ม สำหรับทุกทีมที่รันระบบ production และเห็นภาระ operation โตตามจำนวน service ลูกค้า หรือ developer และทุกที่ที่งาน project แพ้งานแทรกอยู่เรื่อย ๆ การวัดใช้เวลาแค่ไม่กี่นาทีต่อวันตลอดสองสัปดาห์ และมันเปลี่ยน "เรายุ่ง" ให้เป็นชั่วโมงต่องานที่ manager เอาไปตัดสินใจได้
  • ปรับเพดานได้ 50% คือตัวเลขของ Google สำหรับทีม SRE ส่วนทีม operation, ทีม platform เล็ก ๆ หรือทีมในปีแรก อาจตั้งขอบเขตต่างออกไป สิ่งที่สำคัญคือต้องมีขอบเขต วัดเทียบกับมัน และลงมือทำเมื่อทีมอยู่เกินต่อเนื่อง
  • ทีมเล็ก มีเวลาเหลือน้อยที่จะสร้าง automation เลยควรเริ่มจากการปฏิเสธและรวบงานเป็นชุด และจาก self-service ผ่าน pull request ที่มีเอกสารกำกับ แบบนี้แทบไม่ต้องเขียนโค้ด
  • สภาพแวดล้อมที่มี regulation อาจบังคับให้คนต้องอนุมัติการเปลี่ยนแปลงบางอย่าง เก็บขั้นอนุมัติไว้ แต่ทำให้มันเสียแรงน้อย: request แบบมีโครงสร้าง หลักฐานที่เก็บให้อัตโนมัติ และ reviewer ที่มีหน้าที่แค่ review
  • ระบบ legacy ที่แก้ยากและแพง อาจไม่คุ้มที่จะทำ automation ตรง ๆ ตัว workbook อธิบายการห่อมันด้วย automation และ monitoring เป็นทางแก้ขัด จนกว่าจะเปลี่ยนมันได้
  • ไม่คุ้ม กับงานที่นาน ๆ ทำที กับระบบที่ใกล้ปลดระวาง หรือกับ migration ครั้งเดียว เพราะพวกนี้เป็น project มากกว่า toil

กับดักที่เจอบ่อย

  • ทำ automation ให้ process ที่ไม่ควรมีอยู่ cron job ที่ restart consumer ทุก 30 นาทีซ่อน bug ไว้ และความเสี่ยงก็ยังอยู่เหมือนเดิม ให้ถามก่อนว่าทิ้งงานนี้ได้ไหม หรือแก้ที่สาเหตุได้ไหม
  • automation ที่ไม่มีใครเป็นเจ้าของ script ที่คนเขียนย้ายไปแล้ว พังตอน upgrade ครั้งถัดไป แล้ว ticket ก็กลับมา บ่อยครั้งก็หลังเกิด outage ไปแล้ว ให้ automation ทุกตัวมีเจ้าของ, alert และเอกสาร ส่วน workbook ก็คาดหวังให้ทีมรับผิดชอบ toil ที่เกิดจาก tool ของตัวเองที่ไม่มีใครดูแล
  • ทำ automation ให้งานที่นาน ๆ ทำทีจนไม่คืนทุน งาน export 30 นาทีที่ทำปีละสี่ครั้งกินเวลา 2 ชั่วโมงต่อปี ทำให้ automation สามวันต้องใช้ 12 ปีถึงจะคืนทุน เก็บเป็น checklist ไว้แทน
  • toil ที่ไม่มีใครวัด request ใน chat และการขอให้ช่วยแบบผ่าน ๆ ไม่เคยเข้าไปอยู่ในคิวของ ticket ทำให้ toil ดูเล็กกว่าความจริงและค่อย ๆ คืบกลับมา ให้วัดทุกช่องทาง และวัดใหม่ทุกไตรมาส
  • ความเข้าใจหายไป บทเรื่อง automation ของหนังสือ SRE เตือนว่า ยิ่ง automation ทำมาก คนก็ยิ่งได้สัมผัสระบบน้อยลง และยิ่งรันมันเองได้น้อยลงตอนที่ automation พัง เก็บ runbook ไว้ ทำให้ automation แสดงว่ามันทำอะไรไปและทำไม และซ้อมทางทำมือใน game day
  • automation ที่เอื้อมไปไกลเกิน tool ที่มีสิทธิ์ admin เปลี่ยน input ที่ผิดตัวเดียวให้กลายเป็น outage ทั้ง fleet ได้ ตรวจ input ของมันให้ดี และใส่ safeguard ไว้ ตั้งแต่ timeout ไปจนถึงการเช็กสถานะของระบบก่อนมันจะลงมือ
  • โกงตัวเลข การเปลี่ยนป้าย toil ให้เป็น engineering ทำให้อยู่ใต้เพดานได้แค่บนกระดาษ รักษานิยามให้ตรงไปตรงมา และดูชั่วโมงต่องาน ไม่ใช่ดูแค่สัดส่วน