SRE - Roteiro Empresarial e o Conceito UNIX

Olá, sou um inútil.
Foi um dia feliz como um mendigo depois de comer o melhor almoço de sopa, bebida e salada à vontade, que me foi ensinado por colegas de trabalho mais velhos e pessoas mais experientes. Quando você tem sopa com sua refeição, seu nível de felicidade na vida aumenta em cerca de 5. Ah? Qual a proporção de 5? Bem, isso depende do critério de cada um...
Links de URL potencialmente úteis primeiro
- Books For Site Reliability Engineering
- GitHub - dastergon/awesome-sre: A curated list of Site Reliability and Production Engineering resources.
- Roteiro Empresarial SRE
com The Grateful Dead - Darkstar
Uma música famosa usada como nome de host no início do Slackware
Introdução
Li o Roteiro Empresarial SRE uma vez há um mês e hoje o li pela segunda vez.
Embora esteja disponível para compra na O'Reilly, li cerca de metade da primeira parte que também está disponível gratuitamente no URL anterior.
Na primeira vez que li, apenas absorvi as palavras, e na segunda vez, tentei lê-lo novamente. É só isso, mas...
É genérico
O conteúdo do roteiro SRE não usa nomes de produtos reais, mas sim fala sobre os princípios do pensamento, por que são necessários e questões de posicionamento.
Em particular, a consciência de trabalhar em equipe e a ideia de que a carga de trabalho humana não deve ser aumentada. Em relação a este último, existe no conceito de UNIX
- Automatizar tudo
- Para construir um terceiro sistema de forma eficiente
Este ponto se aplica?
Será que deveríamos chamar de engenharia distribuída? À primeira vista, a ideia de que não se deve assumir uma carga de trabalho pesada é um ponto interessante, e acredito que este é o formato ideal.
Além disso, em relação ao conteúdo, no ponto em que as equipes existentes devem se tornar SRE, também menciona não apenas a versatilidade do sistema, mas também a versatilidade humana em ter uma mente aberta para acolher pessoas diversas na equipe.
Tanto na ofensiva quanto na defensiva
É uma organização que deve combinar a operação e construção com uma mentalidade conservadora, juntamente com uma mentalidade de desenvolvimento inovadora.
Senti que os pontos sobre quando ser subserviente e quando não ser foram explicados de forma clara.
Como explicado em Building a Culture of Security and Reliability, se houver uma inclinação excessiva para o 'não', a organização estagnará, e é preciso tomar decisões para assumir riscos quando necessário. Humanamente falando, em uma cultura de negação, mesmo que se tenha boas ideias, elas correm o risco de se tornarem nulas.
Mesmo em conversas triviais, por exemplo, se considerarmos as redes sociais como algo inútil, a chance de obter informações delas diminui. Isso se aplica a todos os meios de coleta de informações; embora se diga 'assistir muita televisão te deixa burro', inversamente, você não conseguirá captar quais informações estão sendo transmitidas na televisão.
No entanto, não é realista para uma única pessoa captar tudo, mas acredito que a comunicação humana pode superar isso.
Mesmo agora, é divertido descobrir coisas novas sobre amigos, mesmo depois de conversar com eles por anos.
Embora eu tenha me desviado um pouco do assunto, no final das contas, se me perguntarem se é uma engenharia que elimina o desperdício em termos de mecanismo, diria que não. Será que é uma engenharia de confiabilidade (de site) que é criada ao encontrar valor agregado em coisas que poderiam ser consideradas desperdício e construir sistemas que eliminam esse desperdício?
Pequeno é belo
Na maioria dos casos, acredito que é inevitável que os sistemas acabem se tornando inchados. Isso é um legado do passado, e sinto que é análogo à contínua emissão de moeda fiduciária por meio de títulos do governo, desde o padrão-ouro.
E o fato de que a moeda emitida por meio de títulos do governo eventualmente se torna uma dívida, não terá pontos em comum com a dívida técnica?
Por mais que se tente manter um sistema pequeno, se o país crescer, ele acabará se tornando gradualmente inchado.
Acredito que a maioria das coisas funciona com este princípio, pois é necessário agir depois que algo se torna inchado, e isso é o mesmo na história.
Como explicado em Simplicity, o que os desenvolvedores que seguem outras filosofias UNIX valorizam ainda mais é que menos código aumenta a legibilidade e a manutenibilidade.
Olhe para o futuro. O futuro chega mais rápido do que você pensa.
Conclusão
Na verdade, eu o li em partes, seção por seção, conforme meu interesse surgia, e sinto que é um livro técnico que pode ser lido com prazer.
Como gosto de ler artigos de entrevistas, o conteúdo que descreve o que os engenheiros reais pensam e o que eles fizeram é muito realista e fácil de absorver.
É uma bênção que isso esteja disponível gratuitamente.
Então. Até a próxima.