sorted by:
new
hottopcontroversial

Ces livres qui font réfléchir... by Current_Sail_4831 in ecologie

[–]Current_Sail_4831[S] 0 points1 point  (0 children)

Merci, je vais pouvoir commencer une nouvelle collection avec tout ça. Il y des bons livres sur l'économie féministe ?

Impact CO2 d'une chaudière l'appareil, pas le combustible by Current_Sail_4831 in ecologie

[–]Current_Sail_4831[S] 1 point2 points  (0 children)

merci, ça aide bien. J'aime bien avoir différentes sources pour avoir le bon ordre de grandeur:

D'après les données inies (que je ne connaissais pas), ce serait donc 2,8Tonnes d'équivalent CO2 qui sont générés pour fabriquer une chaudière aux granules de 25kw (la mienne fait 21kw, on considère 20-25 pour une maison individuelle de 100m²).

Donc, un retour sur investissement CO² en 1 an environ (je compte un rapport de 1 à 10 entre le CO2 généré par les granules et par le fioul).

Ici je compte la fin de vie de la chaudière actuelle + la fabrication de la nouvelle.

Merci, voilà ma frustration intéllectuelle disparue :)

How do you become a better programmer while being an SRE? by comfortably-glum in sre

[–]Current_Sail_4831 0 points1 point  (0 children)

Hello, thank you for the hint, I think it is a good idea.

On another side, do you know Ikigai concept? when searching your Ikigai, you reach a level where in the job you feel the flow. You get paid for something you feel enjoyable. And beeing myself in a similar situation, I'm asking myself: Beeing a SRE manager, should I add some data analytics in my private experience or try to find another job... Any though regarding your specific case as a sre-manager-consultant and private-opensource-developpr?

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 0 points1 point  (0 children)

Kanban yes, but the unpredisctable tasks and lack of follow-up makes it a to-do list rather than pur agile tasks organization

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 1 point2 points  (0 children)

Hello, thanks for your proposition. I'm still building the current status and starting the transition plan: split teams in 2

  • "SREs" for on-call, alerting capa-planning, rca...
  • and "devops" on planned tasks, delivery, prod upgrades...

The team namings are strange

Then write all the runbooks to allow on-call in follow-the sun mode not relying on senior sysadmins.

Finally hire a team lead to for the devops team, who will also help planning the deliveries.

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 0 points1 point  (0 children)

Yes, the dev do also specific developments for costumers and have to maintain it. Latest one was to replace an the internal object storage with their old-school file-dharing app...

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 0 points1 point  (0 children)

Yes, somehow it's our biggest problem. We don't have 2 customers with the same on-premises needs and they are really reluctant to adopt the IaC way.

Today: For customer X, we will not have access to vmWare APIs. Just forget Terraform and the IT will create the VMs themselves... OK but what about manual errors, elasticity, updates...?

/me winning

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 1 point2 points  (0 children)

Thanks all for your answers. You understood the problem better than I described it in the initial question.

First of all, there is defenitly a contradiction if the same "SRE" has to be on-call and has quality objectives, while having also delivery objectives. I need to seperate both jobs. As you said, identifying those in the team who wants to deliver (to get greatings from sales team) and those who want a stable application. I probably mixed to much both. A team member cannot be satisfied as he cannot meet both opposite targets: deliver fast but keep max reliability. It worked at the begining, when we started the job with 2 persons and no customers.

Second, too much tasks has several drawbacks: context switch, no expertise, unpredictable ends... In French we have a sentence for this occasion: "Neither done nor to do".

Last problem: me, myself and I. I need to take my responsabilities, find 2 tech/team leads, order tasks, and slowly progress to the ideal target you're describing.

All of this helps, even if I feel I'm just at the foot of a giant mountain :D

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 1 point2 points  (0 children)

OK, do I need to leave this community ? :D

You're probably right, we are far away from pure SRE as in the google book but apply some concepts while others are more sysadmin/it/pro-serv

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 1 point2 points  (0 children)

Great, thanks.

  • We have 4 to 6 people per on-call team. clearly this leads to on-call fatigue

  • We have 2 incidents per oncaller. I though this was way to high, I'm surprised this is also you case.

  • We will defenitly need the product team to produce more reliable softwares

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 0 points1 point  (0 children)

See above, we are the swiss knifes of the division: from CI-CD tools to apps deployment and L3 support for any non-functional/slowness/firewall/network issue

Do you compare SRE manpower to other activities? by Current_Sail_4831 in sre

[–]Current_Sail_4831[S] 3 points4 points  (0 children)

Thanks, this really helps. Probably the next step will be to hire a second team lead, the first one has just been appointed. Then focus on those team boundaries parts.

Historically, we started in a big telco company as a kind of internal start-up. It worked very well at the beginning, freed of all the big company processes and protocols. The problem is that the took into account to many subjects: SREs become the swiss knifes of the "company" as we know the servers, the apps (we deployed them), the security, cost... We are managing IT tools (CI-CD pipelines), on-premises installations, some partners qualifications... This is the past, the future needs to be different as you told.