LINUX.ORG.RU

История изменений

Исправление shell-script, (текущая версия) :

Миграция сайтов... Мыло-серверов... Я же говорю, ностальгия. :)

А тут нужно не просто уметь мигрировать, а смотреть в код, понимать структуру той же бд. Ты вот там выше ругался на NoSQL(я тоже ругаюсь, хотя полтора года занимался именно кешем), там простой миграцией не обойтись(хотя там тоже есть свои особенности со сбросом кеша на диск и переносом между серверами). Там надо вникать в код, понимать, как сервис с ним работает. Например, перестройка структуры redis-кластера по-разному влияет на работу java-софта и golang-софта. Потому что библиотеки разные, в разных версиях ведут себя по-разному(прости за тавтологию). И там, где достаточно послать SIGHUP, чтобы оно перечитало конфигурацию доступных тысяч нод - это хорошо. А там, где для того же нужно запушить изменения в конфиги, раскатать это всё на инстансы(в нашем случае ansible), уже сложнее.

И(заранее) не надо тут говорить про быдлокодеров, которые ничего не понимают и ничего не умеют. У них тоже свои сложные задачи. А мы, девопсы(я лично себя называю админом, скатившимся до девопса) должны сделать так, чтобы их код работал. Как раньше, когда я был «чистым» админом, я должен был сделать так, чтобы сервер был доступен клиенту. Тогда было проще. Сейчас поменялись инструменты, растолстела инфраструктура, но это неизбежно с ростом завязанных на эту инфраструктуру сервисов и увеличения требований к этому всему.

Когда мы стремимся к пресловутой 99%-ой доступности и непрерывному циклу разработки, когда нас в команде таких не один человек, утерянные технологии предков уже не работают. Нельзя копировать сайтики по ftp/scp, нельзя держать базы без репликации, нельзя держать кеш без кластеризации и многие другие «нельзя».

Исходная версия shell-script, :

Миграция сайтов... Мыло-серверов... Я же говорю, ностальгия. :)

А тут нужно не просто уметь мигрировать, а смотреть в код, понимать структуру той же бд. Ты вот там выше ругался на NoSQL(я тоже ругаюсь, хотя полтора года занимался именно кешем), там простой миграцией не обойтись(хотя там тоже есть свои особенности со сбросом кеша на диск и переносом между серверами). Там надо вникать в код, понимать, как сервис с ним работает. Например, перестройка структуры redis-кластера по-разному влияет на работу java-софта и golang-софта. Потому что библиотеки разные, в разных версиях ведут себя по-разному(прости за тавтологию). И там, где достаточно послать SIGHUP, чтобы оно перечитало конфигурацию доступных тысяч нод - это хорошо. А там, где для того же нужно запушить изменения в конфиги, раскатать это всё на инстансы(в нашем случае ansible), уже сложнее.

И(заранее) не надо тут говорить про быдлокодеров, которые ничего не понимают и ничего не умеют. У них тоже свои сложные задачи. А мы, девопсы(я лично себя называю админом, скатившимся до девопса) должны сделать так, чтобы их код работал. Как раньше, когда я был «чистым» админом, я должен был сделать так, чтобы на сервер был доступен клиенту. Тогда было проще. Сейчас поменялись инструменты, растолстела инфраструктура, но это неизбежно с ростом завязанных на эту инфраструктуру сервисов и увеличения требований к этому всему.

Когда мы стремимся к пресловутой 99%-ой доступности и непрерывному циклу разработки, когда нас в команде таких не один человек, утерянные технологии предков уже не работают. Нельзя копировать сайтики по ftp/scp, нельзя держать базы без репликации, нельзя держать кеш без кластеризации и многие другие «нельзя».