У них все так и было. Но судя по последнему отчету, они потеряли всю backbone network между дата центрами из за ошибки внесения изменений в конфигурацию роутеров (то самое централизованное управление скорее всего, про которое я писал выше). А их днс настроены так, что если теряют связь с основными сервисами, то убирают анонсы по BGP для своих адресов (считается, что данный ДЦ сломался и не надо роутить на него пользователей). И вот так получилось, что все их ДНСы во всех ДЦ потеряли связь по внутренней Backbone сети с каким то центральными сервисами и отозвали BGP анонсы.
В целом моя мысль подтверждается - виной всему излишняя централизация, которая смывает границы "домена проблемы". Сетевые протоколы всегда строились так, чтобы "домен проблемы" (объем затрагиваемых сервисов и устройств в случае точечного сбоя) был как можно меньше. Но централизованное управление ломает этот принцип и раздувает "домен проблемы" до максимальных значений, вопреки изначальному принципу.
А потом все стали переходить от децентрализованной модели изначальной сети к централизованной, где есть выделенные точки управления всей сетью. Руками ходить на каждое отдельное устройство всем надоело, решили разливать изменения всякими модными зумерскими ansible'ами, использовать REST API, NET CONF и прочие централизованные вещи. И вот одно неосторожное движение и вместо единичного отказа лежит уже вся инфраструктура.
Ну например мобильное приложение альфа-банка в один канал пуш уведомлений шлет как спам так и коды подтверждения. Если заблочить эти пуши средствами андроида, то прощай пуши с кодами. Все хитро придумано.
Ну вопрос был не про направленность на внешние/внутренние дела, а именно про то, что девопс это просто способ организации процессов или нет? Если да, то он чем то похож на ITIL, который тоже есть способ организации процессов. Ну что то вроде «чтобы получить результат Х оптимальным быстрым образом, надо делать А, В, С». В ITIL у нас X это внутренний сервис, а в devops это сервис по доставке кода. И поэтому как в ITIL не было специальности «ITIL», а можно было лишь говорить о том, что в компании есть выстроенные по ITIL процессы, так и про devops корректнее говорить, что нет специальности devops, а есть просто выстроенные по devops процессы, которые вполне себе может освоить грамотный админ. Я прав или нет?
В перспективе такие API позволят освободить от работы миллионы инспекторов качества на производственных линиях, погрузчиков на складах, мойщиков окон, сортировщиков товаров, охранников и других низкоквалифицированных работников — продвинутое машинное зрение позволит отдохнуть работникам сотен разных специальностей.
Память закончилась не из за фотографий, а из за ошибки реализации файловой системы, которая приводила к неполному освобождению места при удалении файлов/папок.
У них все так и было. Но судя по последнему отчету, они потеряли всю backbone network между дата центрами из за ошибки внесения изменений в конфигурацию роутеров (то самое централизованное управление скорее всего, про которое я писал выше). А их днс настроены так, что если теряют связь с основными сервисами, то убирают анонсы по BGP для своих адресов (считается, что данный ДЦ сломался и не надо роутить на него пользователей). И вот так получилось, что все их ДНСы во всех ДЦ потеряли связь по внутренней Backbone сети с каким то центральными сервисами и отозвали BGP анонсы.
В целом моя мысль подтверждается - виной всему излишняя централизация, которая смывает границы "домена проблемы". Сетевые протоколы всегда строились так, чтобы "домен проблемы" (объем затрагиваемых сервисов и устройств в случае точечного сбоя) был как можно меньше. Но централизованное управление ломает этот принцип и раздувает "домен проблемы" до максимальных значений, вопреки изначальному принципу.
>А потом, что-то пошло не так.
А потом все стали переходить от децентрализованной модели изначальной сети к централизованной, где есть выделенные точки управления всей сетью. Руками ходить на каждое отдельное устройство всем надоело, решили разливать изменения всякими модными зумерскими ansible'ами, использовать REST API, NET CONF и прочие централизованные вещи. И вот одно неосторожное движение и вместо единичного отказа лежит уже вся инфраструктура.
В перспективе оно оставит их всех безработчными.