Vào ngày 28 tháng 4 năm 2026, Mitchell Hashimoto thông báo rằng Ghostty, trình giả lập terminal mã nguồn mở của anh, sẽ rời GitHub. Anh là người dùng GitHub số 1299, tham gia từ tháng 2 năm 2008 và đã dùng GitHub gần như mỗi ngày trong hơn 18 năm. Lý do không phải là tính năng hay giá, mà là độ tin cậy: anh ghi lại mô hình “gần như mỗi ngày đều có một lỗi X”, và đúng ngày công bố, một lỗi GitHub Actions đã chặn việc đánh giá PR trong hai giờ.
Nếu bạn xây dựng công cụ dành cho nhà phát triển, đây là tín hiệu cần xử lý như một sự cố kiến trúc. Khi một công cụ nằm trên đường dẫn phát hành, review, test hoặc deploy của người khác, độ tin cậy trở thành tính năng cốt lõi. Bài viết này tóm tắt thông báo của Hashimoto và chuyển nó thành checklist thực tế để giảm phụ thuộc nền tảng, đặc biệt với các nhóm API.
Để có thêm ngữ cảnh về công cụ developer trong kỷ nguyên AI, xem cách viết tệp AGENTS.md, cách sử dụng GitHub Copilot và API thanh toán cho các nhóm, và bài viết về bot phân loại Clawsweeper.
Tóm tắt nhanh
- Ghostty sẽ rời GitHub để chuyển sang một forge khác, hiện chưa được công bố.
- Lý do chính: GitHub Actions và các bề mặt nền tảng bị suy giảm quá thường xuyên.
- Repo Ghostty trên GitHub vẫn tồn tại dưới dạng bản sao chỉ đọc.
- Các dự án khác của Hashimoto hiện vẫn ở GitHub.
- Điểm quan trọng không phải là Ghostty chọn nền tảng nào, mà là một người dùng GitHub lâu năm rời đi vì độ tin cậy.
- Bài học cho các nhóm dev tool và API: giảm lock-in, mock dependency, chuẩn bị đường thoát trước khi cần dùng.
Hashimoto đã nói gì?
Trong bài đăng thông báo, Hashimoto không viết một bài công kích dài. Anh mô tả một chuỗi sự cố đã được ghi lại trong nhật ký cá nhân. Nhật ký đó đầy lên nhanh hơn mong đợi. Vào buổi sáng anh viết bài, GitHub Actions gặp lỗi và chặn review PR trong hai giờ.
Kết luận của anh rất rõ:
“Đây không còn là nơi để làm việc nghiêm túc nếu nó cứ chặn bạn hàng giờ mỗi ngày, mỗi ngày.”
Điểm đáng chú ý:
- Đây không phải quyết định bộc phát sau một outage.
- Anh đã theo dõi mô hình suy giảm trong nhiều tháng.
- Sự cố ngày 27 tháng 4 năm 2026 chỉ ảnh hưởng đến thời điểm công bố.
- Ghostty sẽ di chuyển dần dần, không “big bang migration”.
- Repo Ghostty trên GitHub vẫn là mirror chỉ đọc.
Điều anh không nhắc đến cũng quan trọng: không phải Copilot, không phải Microsoft, không phải giá, không phải license. Vấn đề là nền tảng không đủ ổn định cho công việc hằng ngày.
Vì sao đây là vấn đề kiến trúc?
Với một dự án phần mềm, GitHub thường không chỉ là nơi chứa Git repo. Nó còn là:
- issue tracker
- pull request review
- CI/CD
- release artifact
- package registry
- secret store
- identity provider
- automation surface
- webhook source
- project management layer
Bạn có thể clone Git history sang nơi khác bằng một lệnh:
git clone --mirror git@github.com:org/repo.git
cd repo.git
git push --mirror git@gitlab.com:org/repo.git
Nhưng bạn không thể clone toàn bộ hệ sinh thái vận hành đó dễ như vậy:
- lịch sử review PR
- issue discussion
- GitHub Actions secrets
- branch protection rules
- CODEOWNERS workflow
- release automation
- dependency bot config
- marketplace integration
Đây là lý do lock-in thường bị đánh giá thấp. Git phân tán, nhưng quy trình phát triển hiện đại thì không.
Checklist: tự kiểm tra rủi ro nền tảng của bạn
Nếu bạn đang xây dựng dev tool, API platform, CLI, bot review code, SDK hoặc hệ thống CI/CD, hãy kiểm tra 5 điểm sau.
1. Dịch vụ của bạn có nằm trên critical path không?
Hỏi thẳng:
- Nếu công cụ của bạn down 2 giờ, ai bị chặn?
- Developer có thể tiếp tục code không?
- CI có chạy được không?
- Release có bị dừng không?
- Khách hàng có workaround thủ công không?
Nếu câu trả lời là “không thể làm gì”, công cụ của bạn cần tiêu chuẩn reliability cao hơn một dashboard phụ trợ thông thường.
2. Bạn có đo downtime theo giờ làm việc thực tế không?
Uptime 99.9% chưa đủ nếu downtime rơi vào giờ review, deploy hoặc release.
Thay vì chỉ đo tổng uptime, hãy đo thêm:
blocked_developer_minutes =
số developer bị ảnh hưởng
× số phút bị chặn
Ví dụ:
30 developer × 120 phút = 3.600 phút bị mất
Một outage hai giờ có thể không lớn trên trang trạng thái, nhưng là cả buổi làm việc của một team.
3. Bạn có dependency nào không thay thế được không?
Liệt kê các dịch vụ bên ngoài trên đường phát hành:
| Dependency | Dùng để làm gì | Nếu down 4 giờ thì sao? | Fallback |
|---|---|---|---|
| GitHub Actions | CI/CD | Không release được | Runner thứ hai |
| GitHub Packages | Artifact | Không publish được | Registry phụ |
| API provider A | Tính năng chính | Feature lỗi | Mock hoặc provider B |
| OAuth provider | Login | User không vào được | Session cache / provider phụ |
Nếu cột fallback trống, đó là rủi ro cần xử lý.
4. Bạn có mirror repo tự động không?
Một job cơ bản có thể mirror repo sang nền tảng thứ hai hằng ngày hoặc hằng tuần.
Ví dụ GitHub Actions mirror sang GitLab:
name: Mirror repository
on:
schedule:
- cron: "0 2 * * *"
workflow_dispatch:
jobs:
mirror:
runs-on: ubuntu-latest
steps:
- name: Checkout full history
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Push mirror
env:
MIRROR_URL: ${{ secrets.MIRROR_URL }}
run: |
git remote add mirror "$MIRROR_URL"
git push --mirror mirror
Lưu ý: job này vẫn phụ thuộc GitHub Actions. Với repo quan trọng, hãy chạy mirror từ một runner ngoài GitHub hoặc server riêng.
5. Bạn có quy trình release thủ công không?
Tài liệu hóa đường dự phòng:
Nếu CI chính down:
1. Checkout tag release.
2. Chạy test suite cục bộ hoặc trên runner phụ.
3. Build artifact.
4. Ký artifact.
5. Upload lên registry phụ.
6. Cập nhật release note.
7. Thông báo khách hàng.
Nếu quy trình này chưa từng được chạy thử, hãy coi như nó chưa tồn tại.
Các nền tảng thay thế GitHub
Hashimoto chưa công bố Ghostty sẽ chuyển đi đâu. Nhưng nếu bạn đang đánh giá lựa chọn, đây là các hướng phổ biến.
Forgejo
Forgejo là hard fork của Gitea, FOSS, được duy trì bởi Codeberg e.V.
Phù hợp nếu bạn muốn:
- tự host
- kiểm soát dữ liệu
- giảm phụ thuộc vào nền tảng thương mại
- quy trình gần giống GitHub/Gitea
Codeberg
Codeberg là dịch vụ hosted dựa trên Forgejo, vận hành phi lợi nhuận.
Phù hợp với:
- dự án mã nguồn mở
- team không muốn tự vận hành forge
- cộng đồng ưu tiên FOSS
Hạn chế: chưa có mức tương đương GitHub Actions ở cùng quy mô.
GitLab
GitLab có CI/CD mạnh và bộ tính năng đầy đủ.
Phù hợp nếu bạn cần:
- CI/CD tích hợp sâu
- self-host hoặc managed
- project management, security scanning, package registry
Điểm cần cân nhắc: cộng đồng FOSS có nhiều ý kiến trái chiều về một số thay đổi license gần đây.
Sourcehut
Sourcehut tối giản, nhanh, dựa nhiều vào email workflow.
Phù hợp nếu team của bạn thích:
- patch qua email
- giao diện nhẹ
- ít JavaScript
- workflow Unix-style
Không phù hợp nếu bạn cần UX giống GitHub cho contributor phổ thông.
Self-host Forgejo hoặc Gitea
Phù hợp khi bạn cần kiểm soát tối đa.
Đổi lại, bạn phải tự chịu trách nhiệm:
- backup
- upgrade
- monitoring
- security patch
- mail delivery
- runner infrastructure
Radicle
Radicle là hướng peer-to-peer, không phụ thuộc server trung tâm.
Ý tưởng mạnh, nhưng với nhiều dự án công khai, hệ sinh thái vẫn có thể còn quá sớm.
Bài học cho nhóm API
Nếu bạn xây dựng API hoặc công cụ API, hãy thay “GitHub Actions” bằng “API upstream mà sản phẩm phụ thuộc”. Mẫu rủi ro giống nhau:
Khách hàng -> Công cụ của bạn -> API bên thứ ba
Nếu API bên thứ ba down, khách hàng thường không quan tâm lỗi nằm ở đâu. Họ chỉ thấy workflow của họ bị chặn.
Mẫu 1: Mock mọi API upstream quan trọng
Bạn cần mock server để developer vẫn làm việc khi API thật down.
Luồng khuyến nghị:
- Định nghĩa request/response schema.
- Sinh mock server từ schema.
- Chạy test local và CI với mock.
- Chạy contract test định kỳ với API thật.
- Khi upstream lỗi, chuyển môi trường sang mock hoặc degraded mode.
Với Apidog, cùng một định nghĩa API có thể dùng cho tài liệu, test và mock. Điều này giúp team không phải duy trì mock rời rạc bằng tay.
Ví dụ cấu hình endpoint qua biến môi trường:
API_BASE_URL=https://mock.example.internal
API_KEY=test-key
Khi chạy staging:
API_BASE_URL=https://sandbox.provider.com
API_KEY=$STAGING_PROVIDER_KEY
Khi chạy production:
API_BASE_URL=https://api.provider.com
API_KEY=$PROD_PROVIDER_KEY
Mẫu 2: Test với nhiều provider
Nếu sản phẩm của bạn bọc nhiều API AI hoặc API thanh toán, hãy chạy cùng một test suite trên nhiều provider.
Ví dụ cấu trúc test:
const providers = [
{
name: "provider_a",
baseUrl: process.env.PROVIDER_A_BASE_URL,
apiKey: process.env.PROVIDER_A_KEY,
},
{
name: "provider_b",
baseUrl: process.env.PROVIDER_B_BASE_URL,
apiKey: process.env.PROVIDER_B_KEY,
},
];
for (const provider of providers) {
test(`chat completion works on ${provider.name}`, async () => {
const res = await fetch(`${provider.baseUrl}/chat/completions`, {
method: "POST",
headers: {
Authorization: `Bearer ${provider.apiKey}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "default",
messages: [{ role: "user", content: "ping" }],
}),
});
expect(res.ok).toBe(true);
});
}
Nếu Provider A suy giảm, bạn biết Provider B có đang hoạt động không trước khi chuyển traffic.
Xem thêm ví dụ hệ sinh thái API AI trong cách sử dụng API GPT-5.5.
Mẫu 3: Tách release khỏi hosting platform
Nếu toàn bộ release phụ thuộc GitHub Actions, một outage của Actions có thể chặn publish.
Tối thiểu, hãy có:
- runner phụ
- registry phụ
- script build chạy được ngoài CI chính
- tài liệu release thủ công
- artifact signing không phụ thuộc một nền tảng duy nhất
Ví dụ Makefile đơn giản hóa release:
test:
npm test
build:
npm run build
package:
npm pack
release: test build package
./scripts/publish.sh
Khi CI chính down, bạn vẫn có thể chạy:
make release
Quy trình API có khả năng phục hồi với Apidog
Một workflow thực tế cho team API:
- Tải xuống Apidog.
- Tạo project cho từng API upstream quan trọng.
- Định nghĩa schema request/response.
- Sinh mock server từ schema.
- Tạo nhiều environment:
dev,mock,staging,prod. - Lưu credential bằng biến môi trường hoặc secret.
- Viết contract test cho endpoint quan trọng.
- Chạy test với mock trong CI nhanh.
- Chạy test với API thật theo lịch hoặc trước release.
- Khi upstream bị lỗi, chuyển sang mock/degraded mode để tiếp tục phát triển.
Ví dụ environment:
dev:
base_url = http://localhost:3000
mock:
base_url = https://mock.apidog.local
staging:
base_url = https://sandbox.vendor.com
prod:
base_url = https://api.vendor.com
Điểm mấu chốt: mock không phải chỉ để demo. Mock là cơ chế chống downtime cho vòng lặp phát triển.
Checklist triển khai trong tuần này
Nếu bạn muốn áp dụng bài học từ Ghostty ngay, bắt đầu với danh sách ngắn sau.
Ngày 1: Kiểm kê dependency
Tạo file critical-dependencies.md:
# Critical Dependencies
| Service | Purpose | Owner | Outage impact | Fallback |
|---|---|---|---|---|
| GitHub | Source, PR, CI | Platform team | Cannot merge/release | GitLab mirror |
| Provider API | Core feature | Backend team | Feature degraded | Mock/provider B |
| Package registry | Publish SDK | DevEx team | Cannot release | Secondary registry |
Ngày 2: Mirror repo
Thiết lập mirror sang GitLab, Forgejo hoặc Codeberg.
Ngày 3: Tách adapter
Nếu code gọi GitHub API trực tiếp, bọc nó sau interface.
Ví dụ TypeScript:
export interface SourceForgeClient {
listPullRequests(repo: string): Promise<PullRequest[]>;
getIssue(repo: string, id: number): Promise<Issue>;
createComment(repo: string, issueId: number, body: string): Promise<void>;
}
Sau đó triển khai adapter:
export class GitHubClient implements SourceForgeClient {
// GitHub implementation
}
export class GitLabClient implements SourceForgeClient {
// GitLab implementation
}
Mục tiêu: phần còn lại của hệ thống không biết bạn đang dùng GitHub, GitLab hay Forgejo.
Ngày 4: Mock API upstream
Tạo mock cho các API quan trọng. Với API có schema OpenAPI, dùng schema làm nguồn sự thật.
Ngày 5: Viết runbook outage
Ví dụ:
# Runbook: GitHub Actions outage
## Impact
- Cannot run primary CI.
- Cannot publish release from GitHub pipeline.
## Fallback
1. Pull latest release branch.
2. Run `make test`.
3. Run `make build`.
4. Run `make release` from backup runner.
5. Publish status update in Slack.
6. Create post-incident note.
Ngày 6: Chạy diễn tập
Tắt giả định “GitHub luôn hoạt động” trong một buổi:
- không dùng GitHub Actions
- không dùng GitHub Packages
- build từ runner phụ
- publish artifact qua đường dự phòng
Ngày 7: Ghi lại khoảng trống
Sau diễn tập, ghi lại:
- bước nào không chạy được
- secret nào chỉ tồn tại trên GitHub
- script nào phụ thuộc GitHub-specific API
- ai có quyền vận hành fallback
- mất bao lâu để release
Những gì developer đang đọc từ thông báo này
Có bốn phản ứng phổ biến.
“Tốt cho anh ấy”
Nhiều power user của GitHub đã khó chịu vì độ ổn định trong nhiều tháng. Bài đăng của Hashimoto cho họ lý do để công khai hóa vấn đề.
“Chỉ là một outage”
Một số người cho rằng GitHub vẫn có uptime cạnh tranh với ngành. Điều này đúng ở mức vĩ mô, nhưng không giải quyết vấn đề của người dùng bị chặn đúng lúc cần làm việc.
“Rời GitHub rất khó”
Điều này cũng đúng. Issue, PR, CI, release và identity là chi phí di chuyển thực sự. Vì vậy kế hoạch mirror chỉ đọc và di chuyển dần dần của Ghostty là cách tiếp cận hợp lý.
“Repo của tôi có cần rời đi không?”
Không nhất thiết. Nhưng mirror thì gần như luôn đáng làm. Chi phí thấp, lợi ích cao.
Kết luận
Thông báo của Hashimoto không phải lời kêu gọi mọi người rời GitHub ngay lập tức. Nó là lời nhắc rằng mọi nền tảng, kể cả nền tảng mặc định của ngành, đều là dependency bên ngoài.
Nếu bạn xây dựng công cụ dành cho developer:
- đo độ tin cậy theo phút bị chặn, không chỉ uptime
- mirror dữ liệu quan trọng
- mock dependency upstream
- tách adapter khỏi vendor cụ thể
- chạy thử quy trình fallback trước khi outage xảy ra
Với nhóm API, bài học còn trực tiếp hơn: mọi API bên thứ ba đều có thể trở thành GitHub Actions của bạn. Hãy thiết kế để tiếp tục phát triển, test và release ngay cả khi provider chính không hoạt động.
Để xem ví dụ cụ thể hơn về workflow API đa provider, đọc thêm xây dựng các quy trình làm việc bền vững sống sót qua sự cố ngừng hoạt động của nhà cung cấp.
Câu hỏi thường gặp
Ghostty sẽ chuyển đến đâu?
Hashimoto chưa công bố điểm đến. Anh cho biết đang thảo luận với nhiều nhà cung cấp thương mại và FOSS. Repo GitHub hiện tại sẽ vẫn là bản sao chỉ đọc.
Tôi có nên rời GitHub ngay không?
Không nhất thiết. Nhưng bạn nên mirror repo và tài liệu hóa fallback. Di chuyển hoàn toàn chỉ đáng làm khi chi phí outage lớn hơn chi phí migration.
GitHub có thực sự kém tin cậy không?
Vấn đề trong bài đăng không phải chỉ là uptime tổng thể. Vấn đề là các sự cố lặp lại trên các bề mặt quan trọng như Actions, Packages và API có thể cộng dồn thành nhiều giờ làm việc bị mất.
Điều này có ảnh hưởng đến GitHub Copilot không?
Bài đăng không tập trung vào Copilot. Nếu team bạn đang dùng Copilot và cần hiểu billing/API, xem cách sử dụng GitHub Copilot và API thanh toán cho các nhóm.
Điều này có ý nghĩa gì với bot, agent hoặc MCP server dùng GitHub API?
Các công cụ đó thừa hưởng rủi ro độ tin cậy của GitHub API. Bạn nên cache dữ liệu, fail open khi phù hợp, mock API trong test và chuẩn bị adapter cho nền tảng khác. Xem ví dụ trong bài viết về bot phân loại Clawsweeper.
Top comments (0)