Как обезапасить себя и своих близких свой сервер

Вдогонку к размусоливаниям про DevSecOps вот такой важный материал:
https://cheatsheetseries.owasp.org/index.html

Это cheatsheet от OWASP: краткое, но покрывающее очень многие топики, собрание информации по всевозможным темам безопасности приложений.
Собран разными спецами-экспертами в своей области.

Пытаться прочитать все, если вы не безопасник, скорее всего, нет смысла, но полистать и быть знакомым с Open Worldwide Application Security Project точно полезно.

Когда пишете код, думать про безопасность тоже полезно, в тч обращаясь к этой шпаргалке.


Тут top 10 частовстречаемых категорий дыр в безопасности: https://owasp.org/Top10/
(как эти категории собирались: https://owasp.org/Top10/#how-the-data-is-used-for-selecting-categories)

Fantastic Learning Resources

А здесь хороший качественный контент от Алексея Кладова.

1. Отсюда сам сейчас читаю Software Architecture, рекомендую, как и остальные материлы: https://matklad.github.io/2023/08/06/fantastic-learning-resources.html
И блог полистайте, если интересны Rust/Zig/C++ и программирование в целом.

Вообще, Леша раньше преподавал в computer science center, здесь в Питере, вот два крайне годных курса от него на youtube:
2. Плейлист Программирование на Rust: https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e
3. Плейлист Программирование на Python я немного отсюда приворовывал материалы, но никому не говорите!!: https://www.youtube.com/playlist?list=PLlb7e2G7aSpQhNphPSpcO4daaRPeVstku


И гитхаб Леши как отдельный вид искусства: https://github.com/matklad

продолжаем облучение

Why does man print gimme gimme gimme

Пятничная пасхалочка!

https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030

Пора заканчивать про DevOps!

Хаос — часть процесса
Часть 10 из 10 про разный DevOps.

Когда говорим о DevOps и SRE, кажется, что наша цель — создать идеально автоматизированные, устойчивые системы.

Это было бы круто: всё протестировано, отлажено и работает как швейцарские часы. Но реальность такова, что всюду царит хаос, а энтропия никогда не бывает нулевой.

В любой системе всегда найдётся что-то непредсказуемое — от сбоев сети до багов, оставленных тем чуваком, который уволился год назад.


Мы работаем не только с компутерами и кодом, но и с людьми. А люди — это галлюцинирующие обезьяны! Наш мозг обманывает нас, мы делаем ошибки, принимаем решения под влиянием эмоций и опыта (не всегда положительного).


Бизнес-процессы далеки от идеала. Можно проектировать идеальные системы, вводить метрики, устанавливать SLO, но бизнес — это всегда компромисс между скоростью, качеством и необходимостью выживать.

Когда дело доходит до разработки и эксплуатации, процессы "ломаются" на пересечении интересов команд. Инженерам SRE приходится не только поддерживать стабильность, но и справляться с постоянными изменениями требований, а иногда — и с их отсутствием.


В итоге работа DevOps и SRE — это бесконечный цикл улучшений без финиша. В лучшем случае, мы создаём "достаточно хорошую" систему, которую придётся постоянно дорабатывать и оптимизировать.

Это может расстраивать, но такова реальность.


Поэтому задача инженера в этом месте — не сделать идеально по методичке и полностью устранить хаос, а научиться с ним работать, сохраняя гибкость и помня об идеальном направлении, в котором пытаемся идти.

Немного правды

Бонусная Часть 11 из 10 про разный DevOps.

Вообще, что DevOps что SRE -- это сисадмины (ого!), хоть и с разным уклоном.

Да, научившиеся писать код + в идеале понимающие в разработке. Но все-таки больше сисадмины, чем программисты. Точка.


Попробовать переубедить меня можно в комментах.

А пока вот вам мой любимый мем на тему: