Atuin Desktop: Runbook ที่รันได้

 (blog.atuin.sh)
1 คะแนน โดย GN⁺ 2025-04-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Atuin Desktop คือ ตัวแก้ไข runbook แบบ local-first ที่ดูเหมือนเอกสารแต่ทำงานได้เหมือนเทอร์มินัล เป็นเครื่องมือที่มุ่งเปลี่ยนขั้นตอนปฏิบัติการที่ทำซ้ำๆ ให้กลายเป็นเวิร์กโฟลว์ที่แชร์กันได้
  • จัดการทั้งคำสั่งเชลล์, คิวรีฐานข้อมูล, และ HTTP request ร่วมกันภายใน script block พร้อมเทอร์มินัลในตัว, ไคลเอนต์ฐานข้อมูล, และกราฟ Prometheus
  • หาก Atuin CLI มอบ shell history ที่ซิงก์และค้นหาได้ Desktop ก็ขยายแนวคิดนี้ไปเป็น เอกสารที่รันได้ เพื่อไม่ให้ความรู้ของทีมคงอยู่แค่ในความจำของแต่ละคนหรือใน history เท่านั้น
  • ทีม Atuin ใช้งานมันจริงอยู่แล้วกับการปล่อย Atuin CLI, การย้ายโครงสร้างพื้นฐานข้าม environment, การรันงานบน staging/prod, รวมถึงการจัดการและทำงานร่วมกันกับคิวรีฐานข้อมูลจริง
  • ขั้นถัดไปมีแผนเพิ่ม Team accounts และความสามารถในการสร้าง runbook จาก shell history โดยขณะนี้เปิดให้เข้าร่วม early access อยู่

ทำเอกสารให้กับขั้นตอนปฏิบัติการที่เคยพึ่งความจำส่วนบุคคล

  • งานด้านโครงสร้างพื้นฐานจำนวนมากยังพึ่งคำสั่งไม่กี่บรรทัดที่ใครสักคนจำได้ตอนเกิดเหตุขัดข้อง และเอกสารก็มักไม่มีหรือเก่าไปแล้ว
  • เบาะแสที่ใช้แก้ปัญหาจริงอาจกระจัดกระจายอยู่ในเธรด Slack, เอกสาร Notion, หรือ shell history ส่วนตัว
  • Atuin CLI แก้ปัญหานี้ไปบางส่วนด้วย shell history ที่ซิงก์และค้นหาได้ แต่สำหรับทีมยังต้องการมากกว่า history คือ เวิร์กโฟลว์ที่แชร์ร่วมกันได้
  • Atuin Desktop คือตัวแก้ไข runbook แบบรันได้ที่สร้างขึ้นบนแนวคิดว่า “runbook ควรต้องรันได้”
  • ดาวน์โหลดได้จากหน้าดาวน์โหลด

เวิร์กโฟลว์เทอร์มินัลที่รันได้จากในเอกสาร

  • Atuin Desktop ถูกออกแบบมาให้รันเวิร์กโฟลว์เทอร์มินัลจริงจากภายใน UI แบบเอกสาร

  • องค์ประกอบงานที่ถูกรวมไว้ในที่เดียว

    • script block
    • เทอร์มินัลในตัว
    • ไคลเอนต์ฐานข้อมูล
    • กราฟ Prometheus

  • ความสามารถที่มีให้

    • ลดการสลับบริบท: เชื่อมคำสั่งเชลล์, คิวรีฐานข้อมูล, และ HTTP request เข้าด้วยกัน
    • เอกสารที่ไม่เสื่อมสภาพ: รันได้จากในเอกสารโดยตรงเพื่อคงความทันสมัยไว้
    • ระบบอัตโนมัติที่นำกลับมาใช้ซ้ำได้: สร้าง runbook แบบไดนามิกด้วยเทมเพลตสไตล์ Jinja
    • นึกออกได้ทันที: มี autocomplete จาก shell history จริง
    • Local-first, CRDT-powered: สิ่งที่รันได้ในเทอร์มินัล ก็รันได้ใน runbook เช่นกัน
    • ซิงก์และแชร์ผ่าน Atuin Hub: ทำให้ข้อมูลอัปเดตล่าสุดอยู่เสมอระหว่างอุปกรณ์และทีม

กรณีใช้งานจริงและสถานะการเปิดให้ใช้งาน

  • ทีม Atuin ใช้ Atuin Desktop กับงานจริงอยู่แล้ว
    • การปล่อย Atuin CLI
    • การย้ายโครงสร้างพื้นฐานข้าม environment
    • การรันงานบน staging หรือ prod
    • การจัดการและทำงานร่วมกันกับคิวรีฐานข้อมูลจริง
  • ฟีเจอร์ถัดไปที่วางแผนไว้คือ Team accounts และความสามารถในการสร้าง runbook จาก shell history
  • ขณะนี้กำลังทยอยเปิดให้ใช้งาน และสามารถเข้าร่วมได้ผ่าน early access list

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-04-23
ความคิดเห็นบน Hacker News

  • ถ้าคุณสนใจ Emacs สามารถทำงานคล้าย ๆ กันได้ด้วย org-babel
    ไฟล์ข้อความธรรมดาไฟล์เดียวสามารถเป็นทั้งโปรแกรม เอกสาร/โน้ตบุ๊ก/เว็บไซต์ และเป็นตัวอย่างที่น่าเชื่อถือของ literate programming
    คำอธิบายที่ดีอยู่ที่นี่: https://osem.seagl.org/conferences/seagl2019/program/proposa...

    • ในแง่ฟีเจอร์ org-babel ถือว่าอยู่ในกลุ่มที่ทรงพลังที่สุดของระบบ literate programming และอาจเป็นตัวที่แข็งแกร่งที่สุดก็ได้
      ตอนเรียนจากหนังสือโปรแกรมมิงมันช่วยได้มาก และพอกลับมาดู literate program นั้นภายหลัง ก็เข้าใจย้อนกลับมาได้เร็วกว่าตอนอ่านหนังสือครั้งแรกมาก
      ส่วนที่เป็น literate ช่วยตอบคำถาม “โง่ ๆ” ที่เกิดจากการจำเหตุผลหรือความคิดของตัวเองในตอนนั้นไม่ได้ครบ 100%
      แน่นอนว่ามีช่วงการเรียนรู้อยู่ จึงไม่เหมาะกับคนที่ไม่อยากเรียนรู้อะไรแบบนั้น
    • org-babel เหมาะกับงานนี้และสร้างเอกสารที่ยอดเยี่ยมได้
      ลองดูวิดีโอนำเสนอ[0] และ Git repository[1] ที่มีเดโมขั้นสูงกว่าได้
      [0]: https://www.youtube.com/watch?v=0g9BcZvQbXU
      [1]: https://gitlab.com/spudlyo/orgdemo2
    • Shell Worksheets ของ BBEdit ก็คล้ายกัน สามารถผสมข้อความอธิบายกับคำสั่งที่รันได้ด้วยการกดปุ่มครั้งเดียว

  • เคยลองทำสิ่งนี้เมื่อประมาณ 7 ปีก่อน: https://nurtch.com/
    ตัวไอเดียเองมีข้อดีมากมาย และเคยมีการพูดเรื่องนี้ที่ JupyterCon Paris 2023 ด้วย: https://www.youtube.com/watch?v=TUYY2kHrTzs
    เมื่อมีโค้ดที่รันได้อยู่ในเอกสาร ผู้คนก็อยากนำ เวิร์กโฟลว์รีวิว PR มาใช้กับเอกสารด้วย ซึ่งต้องการการลงทุนระดับทีมมากกว่าการแก้ไขวิกิ

    • ความคิดแรกที่ผุดขึ้นมาก็คือ “ทำไมไม่ใช้ Jupyter?” และดีใจที่มีคนคิดเหมือนกัน

  • ตอนอยู่ AWS นี่คือสิ่งที่ทีมเราต้องการพอดี
    มีงานปฏิบัติการจำนวนมากที่เสี่ยงเกินไปเล็กน้อยสำหรับการทำอัตโนมัติเต็มรูปแบบ แต่นี่ให้ เส้นทางในการค่อย ๆ ขยายไปสู่อัตโนมัติแบบทำซ้ำได้ สำหรับงานเหล่านั้น

    • เป็นเพียงความเห็นส่วนตัว ไม่ใช่จุดยืนของนายจ้าง
      อยากรู้ว่าเคยอยู่ AWS ช่วงไหน
      ในช่วงไม่กี่ปีที่ผ่านมา AWS ได้สร้างบริการแพลตฟอร์มภายในที่ช่วยทำให้ runbook ด้านปฏิบัติการเป็นโค้ดและรันอัตโนมัติอย่างปลอดภัย เพื่อลด งานจุกจิกด้านปฏิบัติการ
      Atuin Desktop ก็คล้ายกับบริการนั้นในบางแง่ แต่บริการภายในนั้นมีฟีเจอร์มากกว่ามาก
    • ตอนอยู่ AWS ผมทำสิ่งที่รันได้โดยตรงจากวิกิ
      เป็นการรันสิ่งต่าง ๆ อย่าง query ของ CloudWatch และคำสั่ง AWS CLI พร้อมรับอินพุตจากผู้ใช้ โดยตัดภาระการตั้งค่าในการดึง credential ที่ถูกต้องอย่างปลอดภัยและจัดรูปแบบอินพุตออกไป
      ต่อมาทำใหม่ให้รันได้โดยตรงจาก GitHub และตัวอย่างการเรียกฟังก์ชัน Lambda ด้วยโค้ด 4 บรรทัดจากอินพุตผู้ใช้ใน GitHub wiki อยู่ที่นี่: https://speedrun.nobackspacecrew.com/index.html#invoking-an-...
    • ถ้าเป็นช่วงก่อนโควิดที่อยู่ Amazon น่าจะใช้ Eider เพื่อจุดประสงค์แบบนั้นได้
      มันเป็นโน้ตบุ๊กแบบโฮสต์ที่มีการผสานกับ IAM

  • สงสัยว่าต่างจาก Jupyter notebook แบบรันในเครื่องอย่างไร
    ใน .ipynb ใช้ ! หรือ % ทำแบบนี้ได้ไม่ใช่เหรอ?
    ถามจริง ๆ เพราะไม่ค่อยรู้จักบริษัทนี้หรือผลิตภัณฑ์ CLI ของเขา

    • เหตุผลใหญ่ที่สุดที่ทำให้หลีกเลี่ยง Jupyter notebook ถ้าไม่ได้ใช้ Python ล้วน ๆ คือ Python
      ลำดับที่เริ่มจาก pipenv/pyenv/conda/poetry/uv/dependencies.txt และ “ต้องอัป Python เพื่อรันโน้ตบุ๊กนี้สินะ อืม… ก็ได้” แล้วอีก 2 สัปดาห์ถัดมากลายเป็น “การอัปเกรดนั้นทำ Ansible เก่า ๆ พัง และตอนนี้ซ่อมเซิร์ฟเวอร์ 15 เครื่องที่แทบจะประคองอยู่ไม่ได้แล้ว” นั้นเป็นนรกชัด ๆ
      สำหรับ automation พื้นฐาน ผมพยายามอยู่ให้ห่างจาก Python
      โปรเจกต์ Python ที่ผมดูแลมักพังอย่างน้อยปีละครั้งจากปัญหา dependency หรือ runtime และรวมถึงสิ่งอย่าง Ansible, build pipeline, deploy.py ด้วย
      Jupyter notebook ลาก dependency tree และข้อกำหนดขนาดใหญ่มาด้วย ดังนั้นผมจะไม่ใช้มันกับ automation ที่สำคัญและเป็นพื้นฐานแบบนั้น
      แน่นอนว่างานของผมทำให้ต้องแตะ codebase มากเกินไป และแค่สองเดือนล่าสุดก็มีโปรเจกต์ Python อย่างน้อย 6 โปรเจกต์แล้ว
      บางอันต้องใช้ Python 2.7 บางอันต้องใช้เวอร์ชันของ lib-something.h ที่เลิกใช้แล้ว บางอันล้ำสุด ๆ และบางอันแม้ไม่มีเอกสารแต่จริง ๆ แล้วเข้มงวดมากจนอยู่ในสภาพ “ทำงานได้ตราบใดที่ไม่อัปเดตอะไรบนเครื่องของนักพัฒนาคนเดียวที่รับผิดชอบ”
      Puppet หรือ Chef ก็แย่พอ ๆ กันและเจอปัญหาเดียวกันเพราะเป็น Ruby แต่ต่างกันตรงที่ Ruby มีระบบจัดการแพ็กเกจหลักเพียงระบบเดียวมาหลายสิบปี
    • Jupyter notebook ในฐานะเทอร์มินัลให้ความรู้สึกเหมือน ยัดเยียดให้ทำงานแบบแฮ็ก ๆ อยู่เสมอ เลยอยากลองใช้ตัวนี้ดู
    • มีคำถามเดียวกันแบบ 100%
      โดยทั่วไป Jupyter ให้ความรู้สึกว่ามีทั้งการสคริปต์ที่ยืดหยุ่นและการรองรับคำสั่งของระบบปฏิบัติการ
      ใช้ !/% หรือ os.system() ก็ทำได้

  • อันนี้ดูคล้ายกับ https://runme.dev มาก

    • ผมเป็นผู้ร่วมสร้าง Runme
      ชอบ เอกสารที่รันได้ และคิดว่ายังมีไม่มากพอ

  • ดูน่าสนใจ
    ช่วงหลังเริ่มใช้ https://marimo.io/ เป็น ตัวแทน Jupyter notebook ซึ่งมีการปรับปรุงหลายอย่าง และอันนี้ก็ดูเหมือนเป็นความเคลื่อนไหวไปในทิศทางคล้ายกัน

  • ถ้าเน้น local-first ก็เป็นเป้าของ การผุกร่อน (rot) อยู่แล้ว
    ถ้าไม่ได้รันทั้งหมดในคอนเทนเนอร์ก็เป็นแบบนั้น และถ้ารันในคอนเทนเนอร์ ความเป็น local ก็ไม่สำคัญ
    ถ้าอยากบันทึก runbook ก็แค่บันทึก runbook ไป
    มีวิธีมากมาย เช่น ไฟล์ข้อความ เอกสาร Confluence การอัดหน้าจอ สคริปต์เชลล์ ฯลฯ
    ผู้คนไม่ได้ทำสิ่งนั้นอยู่แล้ว และแค่ UI ดูเท่ขึ้นก็ไม่ได้ทำให้จู่ ๆ ทำกันมากขึ้น
    โดยส่วนตัวแล้วไม่อยากใช้เวลาทั้งวันเขียนโค้ดหรือเอกสารเพื่อทำให้ระบบอยู่ในสถานะ X
    อยากทำสถานะ X ด้วยมือ แล้วใช้เครื่องมือ dump สถานะไว้ จากนั้นภายหลังก็รันเครื่องมือนั้นอีกครั้งเพื่อสร้างหรือบังคับใช้สถานะนั้น
    ไม่อยากอธิบายด้วยโค้ดว่าคอมพิวเตอร์จะไปถึงสถานะนั้นได้อย่างไร และก็ไม่อยากใช้ การตั้งค่าแบบ declarative ซึ่งก็เป็นโค้ดที่เปลี่ยนชื่อเท่านั้น
    อยากลงมือทำเอง ถ่าย snapshot แล้ว replay
    ต้องทำงานได้ทุกที่ บนทุกระบบ โดยไม่ต้องพึ่งการเฝ้าดูคำสั่ง Bash shell อะไรแบบนั้น

    • ถ้าอย่างนั้นก็จะมีแค่ ก้อน binary ของสถานะ ที่ไม่มีเอกสารว่าเหตุใดจึงกลายเป็นสถานะนั้นไม่ใช่หรือ? ดูไม่น่าบำรุงรักษาได้
      Dockerfile จริง ๆ ก็คล้ายกับสิ่งนี้ แต่บันทึกเป็นไฟล์ว่าผ่านขั้นตอนใดบ้างเพื่อไปถึงสถานะนั้น
    • สิ่งที่ต้องการดูใกล้เคียงกับ autoexpect มากกว่า
      https://linux.die.net/man/1/autoexpect
    • ขั้นตอนแบบนั้นโดยทั่วไป portability ต่ำ และต้องทำซ้ำกับแต่ละระบบที่ต่างกัน
      ถึงจุดนั้น การมี คำอธิบายแบบ declarative ที่สามารถแปลงอัตโนมัติเป็นขั้นตอนที่จำเป็นเพื่อไปถึงสถานะ X ได้ น่าจะดีกว่า
    • นั่นแหละคือ declaration ของ Docker
    • สิ่งที่อธิบายดูใกล้เคียงกับ Ansible
      สำหรับงานทั่วไปอย่างตรวจว่ามีการติดตั้งแพ็กเกจหรือไม่ ไฟล์มีอยู่หรือมีเนื้อหาเฉพาะหรือไม่ จะใช้โมดูล และเป็น declarative กับ idempotent

  • สงสัยว่าสิ่งนี้จะเป็น โอเพนซอร์ส เหมือน Atuin CLI และ sync server หรือไม่
    จะถูกทำเป็นผลิตภัณฑ์เชิงพาณิชย์หรือเปล่า?

    • มีแผนจะเปิดเป็นโอเพนซอร์ส: https://news.ycombinator.com/item?id=43766200#43766584
    • คงไม่น่าจะฟรี
      แต่ก็ยินดีที่มีการประกาศออกมา
    • กังวลว่าจะถูกแพลตฟอร์ม rug pull หรือ?

  • ยังไม่ค่อยเข้าใจว่าทำไมต้องมีสิ่งนี้
    ช่วยอธิบายได้ไหมว่าฉันพลาดอะไรไป? ทำไมต้องใช้สิ่งนี้แทน เชลล์สคริปต์ ธรรมดา?

    • ประสบการณ์ที่เคยเจอกับ runbook เป็นแบบนี้
      อยู่ในทีมที่รับผิดชอบหลายอย่าง บางอย่างรู้ดีมากและแตะบ่อย แต่บางอย่างรู้แค่ว่ามีอยู่ราง ๆ และแทบไม่เคยยุ่ง
      X ซึ่งอยู่ในกลุ่มหลังเสีย
      คนที่รู้จัก X จริง ๆ ทั้งหมดลาพักร้อน/เสียชีวิต/ติดประชุม
      โชคดีที่มีเอกสารอธิบายว่าควรทำอะไรในสถานการณ์นี้
      แต่เอกสารนั้นกลับแสดงปาฏิหาริย์ของข้อมูลแย่ ๆ ที่ว่า เก่าและผิด
      นี่คือปัญหาที่สิ่งนี้พยายามแก้
      จากที่ได้คุยกับผู้สร้างมาบ้าง เจตนาน่าจะใกล้เคียงกับการทำอะไรที่อยู่กึ่งกลางระหว่าง Jupyter Notebooks กับ Ansible Tower
      เป็นวิธีที่ทำให้เอกสาร สคริปต์ และ metrics อยู่ใกล้กัน เพื่อให้รู้ได้ง่ายขึ้นว่าอะไรผิดพลาด แก้อย่างไร และสิ่งที่แก้มีผลหรือไม่
      [1] เปิดเผย: ช่วยดูแล atuin Discord อยู่
    • ดูเหมือน literate programming สำหรับเชลล์สคริปต์
      ดังนั้นจึงเป็น “Runbooks That Run”
    • เพราะเขียนด้วย Rust และที่นี่คือ Hacker News
    • โดยปกติการ deploy ถูกจัดด้วยเครื่องมืออย่าง Ansible หรือ Deployer มีจุดประสงค์อะไร? แล้วทำไมต้องแพ็กเกจสคริปต์ Python เพิ่มเติมที่ทำงานทั่วไป แล้วเอาทั้งหมดใส่ไว้ใน Git repository?
      บางคนชอบ workflow หรือ tool flow บางแบบ ก็เลยทำขึ้นมา
      ถ้าเข้ากับคนมากพอ ก็อาจมีตลาดหรือไม่มีก็ได้
      ในโปรเจกต์ส่วนตัว ใช้กระบวนการ deploy ของ PHP เพราะแค่อยากใช้แบบนั้น และมันจัดการงานให้ 60% โดยไม่ต้องทำเอง
      runbook สำหรับสิ่งนั้นคือ task ที่ฝังอยู่ในเครื่องมือ และอยู่ใน Git repository เดียวกับการ deploy เซิร์ฟเวอร์ทั้งหมด
      ไม่อยากเอาไปไว้ในที่สุ่ม ๆ หรือเชลล์สคริปต์ที่ต้องจำคำสั่งแยกต่างหาก
      สำหรับโปรแกรมเมอร์ โค้ดจะกลายเป็น self-documenting โดยแก่นแท้ หากหลีกเลี่ยงความซับซ้อนและรักษาสไตล์ functional ที่เรียบง่าย
      แค่ใส่คอมเมนต์เป็นครั้งคราวเฉพาะส่วนที่ไม่ใช่ flow ง่าย ๆ อย่าง “สร้างผู้ใช้ MySQL, rotate รหัสผ่าน, สะท้อนคู่ผู้ใช้/รหัสผ่านใหม่ไปยังบริการที่เกี่ยวข้อง และลบผู้ใช้เก่าที่พนักงานซึ่งถูกไล่ออกมี credentials อยู่ เผื่อกรณีที่ VPN block อาจล้มเหลว” ก็พอ

  • เครื่องมือในฝันคือเครื่องมือทุกตัวมี terminal interface เพื่อให้สร้างหนังสือเล่มใหญ่ที่รวมบริบททั้งหมดในหัวไว้ได้
    เช่น รวม Jira, Datadog, GitHub ฯลฯ ไว้ในหน้าจอเดียว

    • ส่วนตัวแล้วก็ชอบ TUI ที่เป็นมิตรกับผู้ใช้มากขึ้นอีกหน่อย
      ลองจินตนาการว่ามี internal TUI framework ที่มี component สำหรับแต่ละ internal service แล้วเอามาประกอบกันเหมือนเลโก้เพื่อสร้างแดชบอร์ด TUI ส่วนตัวได้
      ดูเหมือนเป็นงาน side project ที่น่าลองในบริษัท และคงเป็นงานใหญ่มาก แต่ก็น่าสนใจ
    • แค่มี API ก็พอแล้ว และสามารถสร้างเครื่องมือบน API นั้นได้
      ในโลกอุดมคติ อยากให้ทุกบริการ เครื่องมือ และแอปพลิเคชันมี API ที่ฉันใช้ได้
      เช่น ถ้าประตูตู้เย็นเปิดค้างนานเกินไป ก็ตรวจจับด้วยการ polling API หรือ webhook แล้วใช้ Roomba API ส่งไปปิด
      ทำไมจะไม่ได้ล่ะ? นี่คือโลกของ API
    • GitHub และ Datadog มี เครื่องมือ CLI อย่างเป็นทางการอยู่แล้ว
    • อาจหมายถึงอะไรอย่าง wtfutil ก็ได้
      ถึงดูเหมือนการพัฒนาหยุดมา 1 ปีแล้ว แต่แนวคิดประมาณนั้น
      https://wtfutil.com/
    • ถ้าอย่างนั้น คุณอาจชอบ MCP