274 karma · joined March 1, 2018
These are sre focused, the first one indicates if sres are toil driven or overloaded.
The second shows that you have agency as a sre and can have a positive impact.
The third goes into their culture around mistakes, monitoring and on call.
There's so much negative blame torwards the workers for mgmt decisions and the resulting shit.
Ex: we have one dev environment with 250 bare metal machines that each dev can ssh onto any of them. When we transitioned from ClearCase to git git was only installed on 10 of them.
So now sys Admins blame the devs for not requesting them all, devs blame the sys Admins for not knowing it when the reality is the mgmt decision to not prioritize dev prod parity is the problem.
I've always wanted to create some type of monitoring system that displays the entire system in that vein and then model or using control theory.
Has anybody seen a project that does this?
Garbage collection is great until then.
When we reviewed the design I mentioned a few points that were like: "Yeah I know the little requirements you gave counteracted this design, but if we do it this way it'll help us out (source in book)"
This book is really well written, and I've learned so much from it and I keep opening it up every day for further guidance.
OperationCode.org/pageoops
But there's also issues where the carriers play games by reserving flights for specific customers. By customer I mean the travel agent or website.
The middleman isn't checking availability every time because there's a cost to ask the carrier. And if you ask too much they will rate limit or deny you which means you get no availability.
The middleman is a price aggregation person, and tries to find rates and routes using all the rules the carriers specify.
Sure you can buy tickets directly from AA or UA. But what if you want to fly a connection that has both. Do you think AA wants to sell seats on someone's else plane?
The problems I encounter with allocator and heap manager are almost never solved by these types of frameworks. These problems include:
1. Improper usage of the memory returned that contradict implementation. 2. Pool allocators that don't have separation between individual blocks (performance reasons). 3. Specifying the lifetime of the memory to a thread or until specific events happen. 4. Difficult to diagnose corruption, with any tool available.
Here's a specific scenario I deal with very often: There are N persistent worker threads. These worker threads have their own pool of memory, and prior to getting work we know this pool is clean. After the work is finished and before more work is recieved the memory is cleaned. Any excess requested memory is returned to the global-pool, and any memory that is "unmanaged" is dealt with properly.
This means that people can do whatever heap management call you use (void * obtainMemory(size_t);) in the scope of business logic without having to worry about infrastructure concerns.
Having a faster malloc/calloc doesn't benefit me as much as making the usage of memory easier, and the understanding of what happens easier.
It's pretty amazing and I'd recommend it.
Many of the above hint at problems that provide uncertainty and doubt into Travelor itineraries but the discussed topic literally provides more certainty and assists with ensuring less missed connections.
There are some routes and airports that outside of expensive infrastructure cannot handle much more traffic. If you find out you made unreasonable promises you make them reasonable or try and make them possible.
But, as a developer, who has dealt with an absurd amount of bugs that can be prevented from these modern c++ features I really like this.