Live data from Hacker News

A collection of postmortems

github.com

11–19 of 19 posts

Re: A collection of postmortems

#11

Relevant: Foursquare's post-mortem with mongodb. https://groups.google.com/forum/m/#!topic/mongodb-user/UoqU8...

I'm hoping I'm reading this wrong. Because what I'm reading is "A database grew to 67GB on a server with only 66GB RAM". And apparently in that situation you can expect performance to tank until a service is unusable?

Re: A collection of postmortems

#13
It's not really what people usually call post-mortems though. A lot of those stories are just issues regarding products or services and how they were uncovered/fixed. Post-mortems are not limited to that kind of stories at all.

Re: A collection of postmortems

#15
Similarly, see also the RISKS-FORUM digest, with thirty years of archives [1]:

> Its intent is to address issues involving risks to the public in the use of computers. As such, it is necessarily concerned with whether/how critical requirements for human safety, reliability, fault tolerance, security, privacy, integrity, and guaranteed service (among others) can be met (in some cases all at the same time), and how the attempted fulfillment or ignorance of those requirements may imply risks to the public. We will presumably explore both deficiencies in existing systems and techniques for developing better computer systems -- as well as the implications of using computer systems in highly critical environments.

[1] http://catless.ncl.ac.uk/Risks/

Re: A collection of postmortems

#16
post #14

I found it hilarious that they didn't even bother writing a description for Healthcare.gov.

You are the third post to remark on this without adding any further value too the discussion, in a thread of just 11 comments, surely you could have read through them all before posting this?

Re: A collection of postmortems

#17

Relevant: Foursquare's post-mortem with mongodb. https://groups.google.com/forum/m/#!topic/mongodb-user/UoqU8...

I'm hoping I'm reading this wrong. Because what I'm reading is "A database grew to 67GB on a server with only 66GB RAM". And apparently in that situation you can expect performance to tank until a service is unusable?

You did not read that wrong.

The performance tanked because the working set now required a disk hit.

Each, and every, query, required a disk hit.

That many IOs/sec, irrespective of the size could be enough.

Re: A collection of postmortems

#18
post #8
post #2

I think it'd be easier to browse if it'd be organized in a directory structure like: Microsoft/ Outage 1 Outage 2 In case anyone feels like contributing: https://hn.algolia.com/?query=postmortem&sort=byPopularity&p... https://hn.algolia.com/?query=post-mortem&sort=byPopularity&...

I'd rather have them arranged by root cause category (e.g. bad service config, bad network config, units mismatch, inconsistent binary version, software bug, etc) than by which company it affected.

How about both?

    Organization/
        Microsoft/
            Outage 1
            Outage 2
    Category/
        Network/
            Microsoft 1 -> ../../Organization/Microsoft/Outage 1
symlinks are awesome!

Re: A collection of postmortems

#19
post #13

It's not really what people usually call post-mortems though. A lot of those stories are just issues regarding products or services and how they were uncovered/fixed. Post-mortems are not limited to that kind of stories at all.

And post mortems also aren't only limited to startup's that failed :D
Post reply on HN