System-status broadcasting and Heartbit.at
I recently released a small side-project called Heartbit.at. It's basically a small service that consumes the official system-status information from different Internet services and retransmit it in a simpler and centralized place. Unexpectedly during the seeding part of the project I came across many surprises that lead to the thoughts I share below:
I first attempted to create a Twitter list with all the handles of the Internet services I'm interested in. Then, my first surprise—and a prelude of what was about to come—was that I only found less than 10 major services with an official twitter account twitting about their system status. This first deception and frustration lead me to the idea of creating Heartbit.
With a bigger and perhaps a naive hope, I started to code directly on the project. When the seeding part came I found something similar: many major internet services don't even have an official system-status page nor anything similar.
So I ended up consuming data from all type of channels in all type of formats: RSS feeds, Twitter accounts, blog and Tumblr sites, API calls, etc.
The problems and the opportunities
So after all the struggle, I moved on and finished and published Heartbit. It is up and running fine. But I'm not comfortable with the feelings those surprises left on me. The possibilities of improvement for this industry are huge if these, not yet seriously identified problems were addressed correctly. The most important points I consider that must be standardized are the following:
Every major service should have an official status page with at least up-time metrics and events history. Many end-users may not look or understand this information, but the people relying on those services will do, and will definitely find it useful. Having a system-status page for an Internet service should be a standard.
An RSS or Atom feed should also be available for consumption. The objective is to have a human-readable channel available to be informed. Just like the status page but without the necessity to visit the page. In this way interested users can subscribe to the feeds of the services they care and be informed in a centralized application: the feed reader.
A system-status API should also be available for systematic and automatic consumption, not for humans. Companies and technical users could build their own tools to consume the information and propagate it in the way it works better for their organizations. Not to mention that automated actions can be build upon that, but that comes next.
I consider this point to be the most important and the one with the higher potential to improve the whole thing. Allowing a subscription-model for transmitting real-time status of the different levels of the infrastructure or components of a service, will allow dependent services and businesses to build up tools that can automatically react to highly affecting events. Just think a bit on that. The benefits are huge.
Here's a simple example: Imagine a merchant running its business on an e-Commerce system which depends on a payment bridge service such as Stripe for its checkout phase. If at some point the credit card systems of Stripe goes down, Stripe will automatically trigger the webhook and send the notification to all subscribed dependent services. The e-Commerce system will then receive the event allowing it to automatically and in an instant switch the payment bridge provider to another service such as Braintree or PayPal. In this way, the checkout will not be interrupted for the customers and the business will continue for the merchant. Perfect!
Broadcasting this information on the social channels should be also present. Keeping the end-user informed about issues on the layers that affect their direct interaction and experience with the services can potentially decrease the number of technical support tickets and calls.
Having a standardized textual format for redacting the events, or at the very least, the status value of an issue ("updated", "resolved", etc.), will make it easier to consume, automate and understand.
It is well known that on each day our routines, tasks, infrastructures and services rely more and more on even other infrastructures and services. And due to the "nature" of computers and systems, we cannot take for granted that failure will not happen. By being prepared to correctly handle that failure we will drastically diminish its very own chances of happening in the first place.
This note was mirrored on Medium: @JesusLeon.
prguitarman
andulkaphoto
2087
origamiaround
titsay