4 ms·

You'd think by now GH would have a more resilient system in place ... I mean it isn't like it is the first time it happens to them. Thanks for the downvote, my

You'd think by now GH would have a more resilient system in place ... I mean it isn't like it is the first time it happens to them. Thanks for the downvote, my hearts goes to you. :/

starefossen 11y ago
I guess you will get what you pay for... which is nothing for most of their users.
- cbd1984 11y ago
  > I guess you will get what you pay for... 1. There is literally no amount of money which will get you 100% uptime. You may be able to buy guarantees of 100% uptime, however... 2. ... which will not change the fact that things still go down, and that if something goes down in a way which violates your signed contract, the most you can hope for is some kind of monetary compensation and, maybe, an apologetic-sounding employee to scream at until you feel a bit better. If you expect to buy someone's care, you're woefully naïve. My point is that the paying customers don't necessarily get a better service. All they get is limited compensation for enduring the same bad service all of the rest of us get.
  - adwf 11y ago
    It's true that you can't get 100% uptime. And yes 99.999% is more of an SLA agreement/goal than a generally achievable metric. But Github aren't even managing two nines - they only have 98% uptime over the past month. That's bad for any service.
- touristtam 11y ago
  Ok, but I thought the business model here was to be the facebook of code repository. And I don't see the later suffering as many outage as the former (maybe because I am not all day long on FB, mind).
  - TeMPOraL 11y ago
    Because people aren't DDOSing Facebook by telling their CI servers to constantly refetch all the dependencies every goddamn build.
    - i336_ 11y ago
      Hm. Git clients probably supply some anonymous but consistent identifying information when doing a standard pull... per-client rate limiting, anybody? It's a nice idea[l] at least; practically speaking there's enough bandwidth to keep the current disaster ticking over, so... :(
    - mschuster91 11y ago
      NPM and Composer only check for updates and cache locally.
Piskvorrr 11y ago
...which is why we switched to a local instance of Gitlab: stuff still works, no matter whether Github is in business, whether their servers are up, or even whether our internet pipes are up. CLOUDCLOUDCLOUD!!!
- progx 11y ago
  And when you local instance did not work becaus of a disk failure? BACKUPBACKUPBACKUP!!!
  - Piskvorrr 11y ago
    Haven't had a disk failure kill a server for years (spoiler: RAID); and we do follow backup SOP, thankyouverymuch. Moreover, this is far easier to manage than "Github is down, we don't know anything - what happened, why and how, what is affected, when (or whether) it would come back again."

You'd think by now GH would have a more resilient system in place ... I mean it isn't like it is the first time it happens to them. Thanks for the downvote, my hearts goes to you. :/

starefossen 11y ago

I guess you will get what you pay for... which is nothing for most of their users.

cbd1984 11y ago
> I guess you will get what you pay for... 1. There is literally no amount of money which will get you 100% uptime. You may be able to buy guarantees of 100% uptime, however... 2. ... which will not change the fact that things still go down, and that if something goes down in a way which violates your signed contract, the most you can hope for is some kind of monetary compensation and, maybe, an apologetic-sounding employee to scream at until you feel a bit better. If you expect to buy someone's care, you're woefully naïve. My point is that the paying customers don't necessarily get a better service. All they get is limited compensation for enduring the same bad service all of the rest of us get.
- adwf 11y ago
  It's true that you can't get 100% uptime. And yes 99.999% is more of an SLA agreement/goal than a generally achievable metric. But Github aren't even managing two nines - they only have 98% uptime over the past month. That's bad for any service.
touristtam 11y ago
Ok, but I thought the business model here was to be the facebook of code repository. And I don't see the later suffering as many outage as the former (maybe because I am not all day long on FB, mind).
- TeMPOraL 11y ago
  Because people aren't DDOSing Facebook by telling their CI servers to constantly refetch all the dependencies every goddamn build.
  - i336_ 11y ago
    Hm. Git clients probably supply some anonymous but consistent identifying information when doing a standard pull... per-client rate limiting, anybody? It's a nice idea[l] at least; practically speaking there's enough bandwidth to keep the current disaster ticking over, so... :(
  - mschuster91 11y ago
    NPM and Composer only check for updates and cache locally.

Piskvorrr 11y ago

...which is why we switched to a local instance of Gitlab: stuff still works, no matter whether Github is in business, whether their servers are up, or even whether our internet pipes are up. CLOUDCLOUDCLOUD!!!

progx 11y ago
And when you local instance did not work becaus of a disk failure? BACKUPBACKUPBACKUP!!!
- Piskvorrr 11y ago
  Haven't had a disk failure kill a server for years (spoiler: RAID); and we do follow backup SOP, thankyouverymuch. Moreover, this is far easier to manage than "Github is down, we don't know anything - what happened, why and how, what is affected, when (or whether) it would come back again."