Live data from Hacker News

GitLab.com Downtime Postmortem

docs.google.com

21–30 of 50 posts

Re: GitLab.com Downtime Postmortem

#21
post #20
post #2

GitLab B.V. CEO here, please let us know if you have any questions (you can also leave a comment or suggestion in the doc if you want). This whole real-time postmortem is something we thought of to contribute back after having downtime. Feel free to let us know what you think of it.

have you tried HackPad instead of docs?

I have yet to understand why HN:ers like HackPad. It is at best almost as good as GDoc:s on some of the features.

Re: GitLab.com Downtime Postmortem

#23

One important learning from the postmortem: always set your servers up to be in UTC rather than any other time zone. Helps debugging and log correlation and eliminates confusion during incidents.

Very true, we'll update the graph server that was misconfigured.

Re: GitLab.com Downtime Postmortem

#24
post #23

One important learning from the postmortem: always set your servers up to be in UTC rather than any other time zone. Helps debugging and log correlation and eliminates confusion during incidents.

Very true, we'll update the graph server that was misconfigured.

This is a very open and candid write-up. Very much appreciated by the community. Too many companies try to hide/cover-up their outages, but Gitlab is letting it all hang out, their mess-ups as well as things outside their control. I think that speaks a lot to the character of the company, and shows they really care.

Re: GitLab.com Downtime Postmortem

#25

One important learning from the postmortem: always set your servers up to be in UTC rather than any other time zone. Helps debugging and log correlation and eliminates confusion during incidents.

Is that the lesson? Or just that everything should be in the same time zone?

If the company's staff is all in one time zone, I'm inclined to use that for servers, as otherwise people have to mentally juggle two time zones: local and UTC.

Re: GitLab.com Downtime Postmortem

#26
post #20

Earlier quoted context omitted.

have you tried HackPad instead of docs?

I have yet to understand why HN:ers like HackPad. It is at best almost as good as GDoc:s on some of the features.

The reason I've seen it used is that it's open source and therefore can be hosted by the entity involved.

Re: GitLab.com Downtime Postmortem

#27
post #25

One important learning from the postmortem: always set your servers up to be in UTC rather than any other time zone. Helps debugging and log correlation and eliminates confusion during incidents.

Is that the lesson? Or just that everything should be in the same time zone? If the company's staff is all in one time zone, I'm inclined to use that for servers, as otherwise people have to mentally juggle two time zones: local and UTC.

This starts out to be the way most companies think, then before you know it you are big enough to start opening datacenters in other countries, then you have to deal with timestamp conversion.

Re: GitLab.com Downtime Postmortem

#28
post #24
post #23

Earlier quoted context omitted.

Very true, we'll update the graph server that was misconfigured.

This is a very open and candid write-up. Very much appreciated by the community. Too many companies try to hide/cover-up their outages, but Gitlab is letting it all hang out, their mess-ups as well as things outside their control. I think that speaks a lot to the character of the company, and shows they really care.

Thanks Alipus, we're trying to be a part of the GitLab community in everything we do. Even if our operations go south we want that to inform others.

Re: GitLab.com Downtime Postmortem

#30
post #25

Earlier quoted context omitted.

Is that the lesson? Or just that everything should be in the same time zone? If the company's staff is all in one time zone, I'm inclined to use that for servers, as otherwise people have to mentally juggle two time zones: local and UTC.

This starts out to be the way most companies think, then before you know it you are big enough to start opening datacenters in other countries, then you have to deal with timestamp conversion.

Why would you ever need to convert a timestamp? You typically parse a timestamp like "1999-03-29 20:02:04 CEST" and return a number of seconds since a given point in time (e.g. UNIX epoch if it must be). The returned time is obviously +0000 == UTC. If it's not your language/os/software sucks and its no wonder your hair is on fire.
Post reply on HN