Лига Сисадминов

1. Теория.

Зарисовка: Некто Василий решил обновить компьютер. Купил новые комплектующие, установил в корпус. Встал вопрос: Что делать со старым диском? Конечно, ставить в новое железо! Там игры, файлы, программы - лень все заново качать. Довольный собой, Вася нажимает кнопку включения, и получает по щщщам бсод/темный экран/1001 ошибку (нужное подчеркнуть).

Почему так Обэмэ?

Все дело в том, что при установке Винда создает временные файлы, заполняет системный журнал событий и ставит драйвера комплектующих под текущее железо. При перестановке диска в другой компьютер, с отличным от первого железом, система, проще говоря, не поймет как ей работать с новым оборудованием, т.к. настроена для работы с другими комплектующими. То есть, в теории (да и на практике), системный диск можно переставлять из одного компьютера в другой, при абсолютной идентичности оных: одинаковая материнка, одинаковый проц и т.п.

Логичный вывод: нужно каким-то образом "сбросить" уже установленные драйвера и конфигурации. Для этого существует безмерное количество различного софта, но в этом посте я расскажу про встроенную утилиту "sysprep".

2. Утилита sysprep

Утилита позволяет очистить журнал событий, временные файлы, сбросить драйвера устройств и активацию(!) системы, не удаляя пользовательские файлы и программы.

Находится по адресу C:\Windows\system32\sysprep\sysprep.exe

Вызвать можно двумя способами:

1. Зайти по указанному выше адресу, и запустить вручную

2. Нажать сочетание клавиш Win + R и в открывшемся окне ввести sysprep. (бм ругается на скрин :D)

3. Практика

Здесь предстоит выбрать параметры отвязки системы от железа.

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

В итоге должно получиться следующее:

Нажимаем "Ок" и ждем завершения работы утилиты

По завершению, компьютер отключится. Ни в коем случае не включайте его, ибо, в таком случае, всю процедуру придется проводить заново.

Теперь можно переставлять диск в новый комп.

При первой загрузке, винда откроет окно первичной настройки, как при установке. Не пугаемся, просто выбираем нужные пункты и жмем "Да", "Далее" и т.д.

При первичной настройке нужно создать нового пользователя для входа в систему. После завершения всех настроек, его можно будет удалить. Для Windows 10 советую создавать локального пользователя, без подключения к аккаунтам Microsoft, если есть такая возможность (зависит от дистрибутива).

Также, не забываем про то, что sysprep сносит активацию системы. Так что после загрузки ее придется активировать заново.

4. Сфера применения

1. Перенос диска с компьютера на компьютер, как описано выше.

2. Создание бекапа системы и файлов (большинство бесплатных бекап-софтин пляшут от аналогичного скрипта действий)

3. Создание корпоративного дистрибутива с предустановленными программами для установки на офисные машины. Полезно для админов, если нет централизованной системы управления конфигурациями.

5. Заключение

Пост адресован начинающим администраторам и обычным пользователям, оказавшимся в ситуации, схожей с Васиной из начала поста.

Если есть вопросы/дополнения/предложения/критика/замечания - добро пожаловать в комменты, всем рад.

P.S. Чукча не писатель, чукча - технарь.

UPD. Многие говорят что десятка сама прекрасно умеет подсасывать драйвера на новые компоненты. Отчасти это правда, зачастую так и происходит и статья больше относится к Win 7 и 8.1, однако и с десяткой раз на раз не приходится, имею горький опыт.

Внезапно появилось у меня 50 микротиков по филиалам. Задача – настроить бэкап в систему контроля версий и получить возможность выполнить какую-то настройку на всех микротиках, где этой настройки нет. Вторая задача стояла – научиться что-то делать в ansible. Тут ansible не содержит особых преимуществ перед обычным bash скриптом, кроме, может, скорости работы за счет параллельности выполнения.

Все мануалы, что я нашла, содержали инструкцию по бэкапу в ansible одного микротика и такие типа «экстраполируйте сами». Ну зашибись, вся проблема в том, что имя бэкапа задаётся вручную, а если микротиков много, то как-то сделанные бэкапы надо различать.

В микротике есть поле identity и логично было бы именем из identity и называть бэкап. Но вначале я не нашла как его сохранить в переменную и пошла задавать переменные вручную. Кому интересно про identity – переходите к способу 2.

Я опущу, как ставить ansible, задавать пароли и шифровать их, это как раз легко гуглится.

Способ с заданием имени бэкапа в переменной вручную.

ansible_user должен иметь доступ на микротик full, а сервер, с которого запускаете yml должен иметь доступ по ssh на микротик. При этом либо надо разок законнектиться по ssh до этого и сохранить ключи, либо отключить проверку ssh ключей в ansible.

Пикабу съедает пробелы. Ссылка на код текстом будет в конце

Но всё же меня глодала мысль, что можно использовать identity, а тут удачно работа оплатила курсы по всяким там девопс штукам и мне рассказали про register. Так что нет ничего невозможного, смотрите далее.

Способ с бэкапами микротика по identity

Тут проблема в том, что stdout_lines возвращает штуку типа [[u’name: Kostroma]] и как я ни крутила – как к массиву я к ней обратиться не могу. Так что немного через задницу (буду рада, если подскажете красивое решение) из этой строки выковыривается строка с непосредственно identity.

Теперь убираем в hosts file_name

Про то, как делать текстовый бэкап – в примере 1, скрестить ужа с ежом можете сами.

Мой скрипт по запихиванию в систему контроля версий и отсылки на почту. Вот тут я писала подробнее как настроить SVN

#!/bin/bash

now=$(date +"%d_%m_%Y")

rm /usr/scripts/log.txt

ansible-playbook --vault-password-file /etc/ansible/vault_pass_file /usr/scripts/mik-backup.yml >> /usr/scripts/log.txt

cd /usr/svn_backup_repo/DFL_BACKUPS

svn add mikrotik/* --force -q >> /usr/scripts/log.txt

svn commit -m "added backups $now" >> /usr/scripts/log.txt

/usr/bin/mail it@mydomain.ru < /usr/scripts/log.txt -s "Отчет о бэкапах Mikrotik"

Иммутабельность – это неизменность. То есть если уже, например, в файле есть такие изменения, то второй раз они не делаются. Это то, в чем фишка Ansible и то, что не реализовано для микротиков (так как например в firewall важен порядок применения – это одна из причин, почему в его конфиге не поддерживается иммутабельность).

Теперь сюжет из жизни: мне понадобилось вкатить на все микротики одинаковый фильтр сетей OSPF – оставить только серые сети и фильтрануть по маске 10.0.0.0/8. При этом на каких-то микротиках я это уже делала, но не помню на каких. Прощелкать 50 штук – ну такая себе забава.

Итого сливается бэкап в текстовом виде, идет поиск по нужной строке и если она не найдена, то выполняем команду. А если найдена – ничего не делаем. Такая вот псевдо-иммутабельность получается. Да, один скрипт – одна команда, что не очень удобно, под список команд надо дорабатывать.

Сылка на весь код текстом вот

Ну и я не претендую на гуру, только-только начала щупать Ansible, надеюсь кому-нибудь пригодится.

Коллеги и просто сопикабучане, всех неистово приветствую и взываю к великой силе Пикабу, ибо на чудеса она способна немыслимые!

Соорудил я коллегам удобную штуковину для хранения батареек, ну как соорудил -- придумал и начертил, в производство отдал своему куда более пряморукому товарищу, и совместными усилиями получилось нечто следующее (переднее стекло демонтировано для удобства отладки):

Принцип работы достаточно очевиден)

А теперь, уважаемые знатоки, внимание вопрос.

С типоразмером АА проблем не возникает и работает все, как часы, а вот их младшие товарищи из соседнего отсека в одном из примерно 3,5-4 случаев выдают следующую ошибку:

Пытался фиксить рандомным изменением места вклейки костылей спичек -- с мизинчиковыми не помогает(

Прошу свежих идей в комментах, а никнейм того, чье предложение сработает -- разместим на изделии))

Всем солнечной пятницы и по возможности нерабочей субботы ;-)

P.S.: вопрос конечно не слишком сисадминский, но наш брат смышлен, креативен и смекалист, а посему пост публикую в сообществе 

Отказ произошел 11 августа 2016 года и вывел из строя Reddit в общей сложности на 3 часа.

Оригинал статьи можно найти тут.

Общие сведения о проблеме. 11 августа Reddit был не доступен в период с 15:24 до 16:52 (это и все нижеследующее премя представлено в PDT), а в период с 16:52 до 18:19 имел проблемы с производительностью. Проблема затронула все официальные платформы Reddit и API, обслуживающие сторонние приложения. Простой был вызван ошибкой, возникшей во время миграции критической составляющей бэкенда. В результате инцидента данные потеряны не были.

Причина ошибки и ее исправление. Reddit использует Zookeeper для мониторинга работы серверов. Также используется система автомасштабирования для обеспечения необходимого числа серверов, зависящего от нагрузки на систему.

Часть обновлений инфраструктуры включала в себя миграцию Zookeeper на более современную платформу, внутри облаков Amazon. Так как система автомасштабирования получает данные напрямую из Zookeeper, то на время миграции она была отключена, чтобы у нее не возникало путаницы в том, какие сервера должны быть доступны. Однако, в 15:23 система была неожиданно запущена менеджером пакетов, заметившим ручное изменение конфигурации. За 16 секунд запущенная система, выполнив чтение данных частично перенесенного Zookeeper, отключила множество серверов, обслуживающих основной сайт, API и системы кэширования.

В 15:24 инженер Reddit заметил, что серверы были отключены, и в 15:47 перевел сайт в "нерабочее состояние", чтобы восстановить работу всех серверов. К 16:42 все сервера были запущены. Однако все кэши в это время были пусты, что привело к увеличению нагрузки на базы данных и, как следствие, к снижению производительности. В 18:19 время отклика было в норме и все системы работали нормально.

Профилактика. Модернизация инфраструктуры будет порождать различные типы миграции серверов. Так как вышеописанный сбой был связан с уникальной и выскорисковой миграцией, то специалисты Reddit не предполагают, что имевшая место комбинация сбоев в будущем в точности повторится. Однако, они определили следующие несколько улучшений, которые должны повысить общую устойчивость системы к ошибкам, возникающих при критических миграциях:

- сделали систему автомасштабирования менее агрессивной, уменьшив количество серверов, которые она может единомоментно остановить;

- изменили регламент миграций так, чтобы критические операции выполнялись инженерами в паре;

- реализовали корректную остановку менеджера пакетов, чтобы избежать неожиданного запуска сервисов в будущем.

В заключение. Инженер Reddit (судя по всему, пост, на который дана ссылка выше, написан именно им) и вся компания принесла извинения за вызванные перебои в работе сайта, сообщив также, что завершилась большая веха в процессе миграции, позволяющая ускорить как производительность самого сайта, так и процесс его разработки.

Прежде чем создать курс, продакт оунеры Слёрм вооружаются улыбкой и проводят кастдевы с опытными специалистами, потенциальными спикерами, корпоративными заказчиками.

С кастдевов по курсу Слёрм «Python для инженеров» получилась интересная подборка практических кейсов автоматизации задач эксплуатации на Python в зарубежных и наших компаниях.

Кейс первый: облачный.

Компания активно пользуется облаком и тратит 2 миллиона рублей в месяц на инфраструктуру в AWS. Можно написать инструмент на Python, который будет анализировать и отключать «холостые ресурсы». Это позволит сократить расходы на 40-50% или около 12 миллионов рублей в год.

Кейс второй: экзотический.

У компании много экзотических сервисов, которые необходимо мониторить. Можно написать несколько Prometheus-exporter'ов на Python, что позволит эффективнее мониторить приложения и свести к минимуму простой платформы. Актуально для Fintech, ADtech, крупных медийных, социальных и сервисных площадок.

Кейс третий: Ansible.

Часто документация о серверах ведётся в Jira. Иметь единый источник информации хорошо, но переносить серверы из Jira куда-либо - неудобно. Пример с Ansible. Можно держать честный инвентори в Ansible-репозитории и по завершении деплоя обновлять страницу в Jira, записывая какие сервера для каких целей используются. Или можно с помощью Python генерировать status page - писать, какие версии каких сервисов сейчас задеплоены в каждом environment.

Кейс четвёртый: Chef.

У меня был случай, когда я писал сводную систему chef-opscode + AWS + [webazilla.com](http://webazilla.com/), чтобы понимать за что и сколько мы платим. Chef в качестве глобального инвентори + базовая статистика по загрузке системы + провайдерские API.

Кейс пятый: lint-тесты.

В практике был опыт написания на Python lint-тестов для ansible и kubernetes. Они позволяли проверять на наличие обязательных параметров, которые были стандартными в рамках компании. Без автоматизации проверяли руками и глазами, что конечно же намного дольше и неэффективней.

Кейс шестой: zabbix.

Была написана прослойка между системой мониторинга и внутренним таск-менеджером. Скрипт получает сырые алерты от zabbix, обрабатывает их в соответствии с определенной логикой и создает конкретную задачу в трекере. Дежурные специалисты оперативно получают точную информацию и не тратят время на выяснение «очага возгорания» среди сотен клиентских серверов.

Кейс седьмой: саппорт.

Автоматизация рутинных задачи для саппорта. Раньше приходил клиент и писал запрос на изменение конфигурации (напр., увеличить диска на гипервизоре и/или диск внутри виртуальной машины), специалист техподдержки шел и руками менял конфигурацию, после этого вносил изменения в биллинг.

Это занимало в среднем 5 минут на одного клиента, аналогичных задач было 7-10 штук в день. После автоматизации процесса с помощью Python затраты на задачу сократились до 15 секунд. Экономия в месяц — примерно 23 часа. В качестве бонуса увеличилась лояльность клиентов, ведь теперь их запросы обрабатывались в считанные секунды.