Один день из работы
Часть первая
Итак, вчера был админский день, я обновляла debian (с 10 на 11) и zabbix (с 5.4 на 6.2), и хочу рассказать, как это происходило. Ведь не думаете же вы, что есть волшебная кнопка "обновить"?
Вообще, почему мне ударило в голову обновляться? Безопасники провели аудит и сказали закрыть уязвимости. В принципе, все они упирались в версию OpenSSH и Apache.
Вечером накануне написала в чатик, что заббикс будет недоступен весь завтрашний день в связи с обновлением. Сервис не является критичным, а потому можно действовать наживую в рабочее время. Утром повторила оповещение, что начинаю работы.
Прихожу я на работу рано, до восьми, и под кофеёк решила начать с OpenSSH. Пошла, сначала сделала apt update. В выводе мне любезно сообщили, что "публичный ключ недоступен". Аж два раза. Пошла в гугл, нашла как обновить ключи, обновила, записала в рабочую вики для потомков. Ни install, ни --only-upgrade ничего не обновляли, говорили, что у вас самая распоследния версия. Ну я же знаю, что они врут) Пошла поискала ещё, нашла, что надо обновлять с указанием buster-backports. Добавила в sources.list, обновила список пакетов. Попробовала обновить, ssh сказал, что ему надо в зависимостях openssh-sftp-server. Обновила оба, ура, новая версия.
Вспомнила, что вчера общала Питеру надыбать коммутаторы перекантоваться до закупки. Написала в Пятигорск, у них была заначка.
Все предыдущие разы заббикс у меня переезжал сразу на новую версию, на новый сервер с новым debian. Всё потому, что я малодушно забивала на обновления. Базы каждый раз не конвертировались в новую версию (через две) нормально, так что переезжал без данных. Экспорт-импорт хостов и шаблонов, остальное за день допиливалось. Последний раз я пообещала себе не ждать когда выйдет версия сразу через две-три мажорные, а регулярно обновлять. Ну а тут как раз повод удобный. К тому же заббикс оброс пользаками, уведомлениями и прочим, что требует таки переноса БД в новую версию.
Как раз пришли инфраструктурщики и я попросила снять снапшот с виртуалки. Заодно посмотрели, что проц периодически уходит в потолок и пообщали при ребуте пару ядер накинуть.
Сначала я попробовала просто проапгрейдить заббикс сервер так, как написано у них на сайте. В инструкции был этап бэкапа БД и настроек и я его тоже выполнила, хотя у меня и был снапшот. Но много бэкапов не бывает. Поискала как бэкапить mysql, я с ним работаю раз в два года, поэтому команд не помню. Задумчиво посмотрела, как тает место на диске.
Пока sql молотил бэкап вспомнила, что руководство вышло из отпуска, а мы хотели презентовать новую приблуду к астериску. Написала, напомнила, что у нас есть презентация.
Попытка апгрейда zabbix-server - он апгрейдиться отказался, сказал, у вас самая новая версия. Знакомая, однако, песня. Потом я попробовал действовать насильно как с OpenSSH, он радостно даунгрейднулся до версии 4 и отказался запускаться. Я вернула 5.4, он восстал.
Почитала почту, подумала как ответить человеку, не нарушая корпоративную этику. Придумала, но решила промолчать. Выполнила пару заявок по сети.
Почитала внимательнее заметки по обновлению и пришла к выводу, что надо апгрейдить debian. Ни разу у меня это раньше не проходило без факапов, так что я решила бэкап БД и настроек слить ещё на соседний сервер, хотя было лениво. В снапшоте не было бэкапа БД и если бы из него восстанавливали и что-то пошло не так, у меня не оказалось бы валидной копии данных, так что я поборола лень, поискала, куда можно приткнуть 40 гиг базы и запустила scp. Заодно на всякий случай опять экспортнула хосты и часть шаблонов.
Подумала, а не обновиться ли сразу на 12 debian, вспомнила, что обновление через две версии ничем хорошим не заканчивалось и решила пока остановиться на 11.
#будни
Часть два сразу же дальше, в один пост не влезло
Часть первая
Итак, вчера был админский день, я обновляла debian (с 10 на 11) и zabbix (с 5.4 на 6.2), и хочу рассказать, как это происходило. Ведь не думаете же вы, что есть волшебная кнопка "обновить"?
Вообще, почему мне ударило в голову обновляться? Безопасники провели аудит и сказали закрыть уязвимости. В принципе, все они упирались в версию OpenSSH и Apache.
Вечером накануне написала в чатик, что заббикс будет недоступен весь завтрашний день в связи с обновлением. Сервис не является критичным, а потому можно действовать наживую в рабочее время. Утром повторила оповещение, что начинаю работы.
Прихожу я на работу рано, до восьми, и под кофеёк решила начать с OpenSSH. Пошла, сначала сделала apt update. В выводе мне любезно сообщили, что "публичный ключ недоступен". Аж два раза. Пошла в гугл, нашла как обновить ключи, обновила, записала в рабочую вики для потомков. Ни install, ни --only-upgrade ничего не обновляли, говорили, что у вас самая распоследния версия. Ну я же знаю, что они врут) Пошла поискала ещё, нашла, что надо обновлять с указанием buster-backports. Добавила в sources.list, обновила список пакетов. Попробовала обновить, ssh сказал, что ему надо в зависимостях openssh-sftp-server. Обновила оба, ура, новая версия.
Вспомнила, что вчера общала Питеру надыбать коммутаторы перекантоваться до закупки. Написала в Пятигорск, у них была заначка.
Все предыдущие разы заббикс у меня переезжал сразу на новую версию, на новый сервер с новым debian. Всё потому, что я малодушно забивала на обновления. Базы каждый раз не конвертировались в новую версию (через две) нормально, так что переезжал без данных. Экспорт-импорт хостов и шаблонов, остальное за день допиливалось. Последний раз я пообещала себе не ждать когда выйдет версия сразу через две-три мажорные, а регулярно обновлять. Ну а тут как раз повод удобный. К тому же заббикс оброс пользаками, уведомлениями и прочим, что требует таки переноса БД в новую версию.
Как раз пришли инфраструктурщики и я попросила снять снапшот с виртуалки. Заодно посмотрели, что проц периодически уходит в потолок и пообщали при ребуте пару ядер накинуть.
Сначала я попробовала просто проапгрейдить заббикс сервер так, как написано у них на сайте. В инструкции был этап бэкапа БД и настроек и я его тоже выполнила, хотя у меня и был снапшот. Но много бэкапов не бывает. Поискала как бэкапить mysql, я с ним работаю раз в два года, поэтому команд не помню. Задумчиво посмотрела, как тает место на диске.
Пока sql молотил бэкап вспомнила, что руководство вышло из отпуска, а мы хотели презентовать новую приблуду к астериску. Написала, напомнила, что у нас есть презентация.
Попытка апгрейда zabbix-server - он апгрейдиться отказался, сказал, у вас самая новая версия. Знакомая, однако, песня. Потом я попробовал действовать насильно как с OpenSSH, он радостно даунгрейднулся до версии 4 и отказался запускаться. Я вернула 5.4, он восстал.
Почитала почту, подумала как ответить человеку, не нарушая корпоративную этику. Придумала, но решила промолчать. Выполнила пару заявок по сети.
Почитала внимательнее заметки по обновлению и пришла к выводу, что надо апгрейдить debian. Ни разу у меня это раньше не проходило без факапов, так что я решила бэкап БД и настроек слить ещё на соседний сервер, хотя было лениво. В снапшоте не было бэкапа БД и если бы из него восстанавливали и что-то пошло не так, у меня не оказалось бы валидной копии данных, так что я поборола лень, поискала, куда можно приткнуть 40 гиг базы и запустила scp. Заодно на всякий случай опять экспортнула хосты и часть шаблонов.
Подумала, а не обновиться ли сразу на 12 debian, вспомнила, что обновление через две версии ничем хорошим не заканчивалось и решила пока остановиться на 11.
#будни
Часть два сразу же дальше, в один пост не влезло
👏8
Один день из работы
Часть вторая
Дальше по инструкции - апгрейд всех пакетов, очистка, замена sources.list, снова апгрейд. Поотвечать на вопросы обновлятора. Дописала новые репозитории заббикса, удалила старые. Апгрейд. В процессе спросили, хочу ли заменить конфиг сервера? Посмотрела diff, там чего-то много добавилось, сказала заменить на новую версию. Конфиг апача? Ничего нового, оставить старый.
Сходила на маленькое совещание. Попросили одну штуку сделать красиво. Сказала: или доработка контрагента за деньги, или я подумаю, но не прямо сейчас. Сказали, подождут, пока думаю.
Открыла конфиг zabbix-server, открыла старый конфиг из бэкапа, прописала все параметры снова. Удивилась, сколько я, оказывается, на кэши выделила, просуммировала и поняла, отчего у него память вся выжрата на кэши. Стартанула заббикс - не стартует. Полезла в логи заббикса - ошибка подключения БД. Полезла в логи mysql - подключение с неверным паролем. Полезла в старый конфиг, ага, неправильно скопировала пароль. Поменяла, стартанула заббикс - ура, поднялся!
Потыкала в консоль. Йолки, я х.з. теперь как посмотреть список графиков, если он не умещается в окошко. Надо поискать. Хосты с заббикс клиентами не зеленеют. Посмотрела, данные есть, триггеры работают, значит не страшно. Скачала свежий виндовый клиент. Попробовала обновить клиента на каком-то сервере - позеленел. Поставила задачу инфраструктурщикам на обновление.
Написала в чатик, что обновление закончила.
Позвонил сотрудник, обрадовал, что мы 4 дня в дальнем филиале пытали провайдера инета подключить нам sip, тогда как телефонный номер принадлежит другому провайдеру. Ну, бывает. В филиале шесть человек, айтишника нет, а последний мужик уволился три месяца назад.
Посмотрела версию OpenSSH, оппа, опять 8.4 - откатилась. Попробовала обновить как на десятке - фокус не удался, отложила на завтра.
Ну, вот как-то так 😅
Часть вторая
Дальше по инструкции - апгрейд всех пакетов, очистка, замена sources.list, снова апгрейд. Поотвечать на вопросы обновлятора. Дописала новые репозитории заббикса, удалила старые. Апгрейд. В процессе спросили, хочу ли заменить конфиг сервера? Посмотрела diff, там чего-то много добавилось, сказала заменить на новую версию. Конфиг апача? Ничего нового, оставить старый.
Сходила на маленькое совещание. Попросили одну штуку сделать красиво. Сказала: или доработка контрагента за деньги, или я подумаю, но не прямо сейчас. Сказали, подождут, пока думаю.
Открыла конфиг zabbix-server, открыла старый конфиг из бэкапа, прописала все параметры снова. Удивилась, сколько я, оказывается, на кэши выделила, просуммировала и поняла, отчего у него память вся выжрата на кэши. Стартанула заббикс - не стартует. Полезла в логи заббикса - ошибка подключения БД. Полезла в логи mysql - подключение с неверным паролем. Полезла в старый конфиг, ага, неправильно скопировала пароль. Поменяла, стартанула заббикс - ура, поднялся!
Потыкала в консоль. Йолки, я х.з. теперь как посмотреть список графиков, если он не умещается в окошко. Надо поискать. Хосты с заббикс клиентами не зеленеют. Посмотрела, данные есть, триггеры работают, значит не страшно. Скачала свежий виндовый клиент. Попробовала обновить клиента на каком-то сервере - позеленел. Поставила задачу инфраструктурщикам на обновление.
Написала в чатик, что обновление закончила.
Позвонил сотрудник, обрадовал, что мы 4 дня в дальнем филиале пытали провайдера инета подключить нам sip, тогда как телефонный номер принадлежит другому провайдеру. Ну, бывает. В филиале шесть человек, айтишника нет, а последний мужик уволился три месяца назад.
Посмотрела версию OpenSSH, оппа, опять 8.4 - откатилась. Попробовала обновить как на десятке - фокус не удался, отложила на завтра.
Ну, вот как-то так 😅
👏6👍1
Обновление - оно для крепких духом
А свежеобновлённый заббикс подумал-поработал и решил немного упасть ближе к вечеру пятницы. Причем здорово так - только данные в графики перестал собирать и только по snmp. При этом коннект с хостами не терялся и даже алерта типа "no snmp data collection" не было. Только графики пустые, что было обнаружено сегодня.
Выяснено: в какой-то момент пошли ошибки записи в БД. В новой версии mysql один параметр конфига стал считаться устаревшим и игнорировался, а два других вместо него не были прописаны. Также ему перестал нравиться max_allowed_packet, судя по логам именно из-за него всё падало, и его пришлось уменьшить (от чего он такой большой был - история не сохранила). Ну вот, теперь смотрю в логи, медитирую упадёт/не упадёт.
OpenSSH 9.2 кстати, удалось поставить только с указанием репы от debian12. Ну, надеюсь, он мне ничего не сломает.
Известная картинка, чтоб посмотреть на всю неизбежность на неё надо кликнуть.
А свежеобновлённый заббикс подумал-поработал и решил немного упасть ближе к вечеру пятницы. Причем здорово так - только данные в графики перестал собирать и только по snmp. При этом коннект с хостами не терялся и даже алерта типа "no snmp data collection" не было. Только графики пустые, что было обнаружено сегодня.
Выяснено: в какой-то момент пошли ошибки записи в БД. В новой версии mysql один параметр конфига стал считаться устаревшим и игнорировался, а два других вместо него не были прописаны. Также ему перестал нравиться max_allowed_packet, судя по логам именно из-за него всё падало, и его пришлось уменьшить (от чего он такой большой был - история не сохранила). Ну вот, теперь смотрю в логи, медитирую упадёт/не упадёт.
OpenSSH 9.2 кстати, удалось поставить только с указанием репы от debian12. Ну, надеюсь, он мне ничего не сломает.
Известная картинка, чтоб посмотреть на всю неизбежность на неё надо кликнуть.
🔥8
Эффект присутствия
Все слышали про "эффект присутствия", когда техника и софт в присутствии админа начинают работать как надо.
Так вот, через пару месяцев эникейства у меня стал проявляться обратный эффект - в моём присутствии всё, что работало "плохо" переставало работать вообще. Тормозящие программы зависали, медленно печатающие принтеры переставали это делать в принципе и т.д.
Пришлось довольно долго переживать этот период. Эффект присутствия в его нормальном виде стал проявляться только через год.
Это всё относится опять же к опыту использования различных ИТ и инженерных систем. Ваши правильные вопросы, заданные пользователю, а также микродействия начинают приводить к результату раньше, чем происходит осознанная реакция. Ну и магия, конечно.
Все слышали про "эффект присутствия", когда техника и софт в присутствии админа начинают работать как надо.
Так вот, через пару месяцев эникейства у меня стал проявляться обратный эффект - в моём присутствии всё, что работало "плохо" переставало работать вообще. Тормозящие программы зависали, медленно печатающие принтеры переставали это делать в принципе и т.д.
Пришлось довольно долго переживать этот период. Эффект присутствия в его нормальном виде стал проявляться только через год.
Это всё относится опять же к опыту использования различных ИТ и инженерных систем. Ваши правильные вопросы, заданные пользователю, а также микродействия начинают приводить к результату раньше, чем происходит осознанная реакция. Ну и магия, конечно.
👍9
Не только админский день
Оказывается, я изобрела велосипед. Ставить пакеты из определенного репозитория определенного дистрибутива линухи - это нормально, так делают, я не одинока.
Обновила на сервере с которого бэкапится сетевое оборудование OpenSSH. Почувствовала прям сразу - бэкапы сломаются. Запустила скрипт и точно: извини, иди нафиг на 11й строке. Что там? Ssh, конечно. Пробую отдельно применить ключ, подключиться по ssh. Ключ не валидный говорят. Опять же, чувствую, что дело в длине ключа, хуавеи желают 1024. Для верности пробую другой ключ для пуша в git. Он длиной 2048 и он работает.
Лезу гуглить что-нибудь про "enable 1024 key rsa openssh". Первая страница гугла не радует. Запускаю ssh с флагом -vvv. Ох, читаю сочинение о коннекте на две страницы: робкий обмен данными, поиск в трёх файлах известных хостов, перебор алгоритмов и в конце отказ. No mutual signature algoritm. С этой фразой уже всё ищется как надо, правится конфиг клиента и всё работает.
По-хорошему, нужно было почитать release notes и только потом обновляться. Но опять же, сервис не критичный, можно и откатиться..
Немного менеджерского:
Пытаюсь заставить джуна написать план установки патча. Учесть это, это, сообщить этим, чтоб дернули службу на связанном сервисе, проверка работоспособности. Нет, просто "я поставлю патч" не подходит. Ощущение, что я мучаю котёнка, а всего-то хочу научить человека планировать и проводить изменения (желательно, без моего участия). И забить не могу, потому что сервис критичный. Надо бы найти ему что-то не столь критичное и кинуть одного работать, что ли, чтобы натолкнулся на "всё сломалось" и спроецировал на критичный сервис. Чувствую в себе двойные стандарты (оглянулась на поломанный и починенный ssh, вздохнула).
Другая проблема: в программе отражаются неправильные должности, поэтому ей нельзя официально пользоваться. Должности берутся из AD. Почему в AD неправильные? Так сложилось. Можно ли брать должности из 1С? Можно, но у 1с-ников расписано время на текущие задачи, можем ли мы вклиниться? Можем, давайте через 2 недели. А может, заодно и в AD будете сразу выгружать из 1С? Нет, должности длинные, надо менять схему AD, инфраструктура не хочет. И некому писать интеграцию. Но 1с-ники выгрузят diff и навесят задач на саппорт менять руками. Или инфраструктура напишет скрипт, но не факт. Может тогда нафиг пока выключим отображение должностей в софте, чтоб морально не страдали? Если будет очень надо выключим, но пока ждём. И по кругу на телефоне и ножками: начальник-> 1C-> программер-> бизнес-заказчик.
#будни
Оказывается, я изобрела велосипед. Ставить пакеты из определенного репозитория определенного дистрибутива линухи - это нормально, так делают, я не одинока.
Обновила на сервере с которого бэкапится сетевое оборудование OpenSSH. Почувствовала прям сразу - бэкапы сломаются. Запустила скрипт и точно: извини, иди нафиг на 11й строке. Что там? Ssh, конечно. Пробую отдельно применить ключ, подключиться по ssh. Ключ не валидный говорят. Опять же, чувствую, что дело в длине ключа, хуавеи желают 1024. Для верности пробую другой ключ для пуша в git. Он длиной 2048 и он работает.
Лезу гуглить что-нибудь про "enable 1024 key rsa openssh". Первая страница гугла не радует. Запускаю ssh с флагом -vvv. Ох, читаю сочинение о коннекте на две страницы: робкий обмен данными, поиск в трёх файлах известных хостов, перебор алгоритмов и в конце отказ. No mutual signature algoritm. С этой фразой уже всё ищется как надо, правится конфиг клиента и всё работает.
По-хорошему, нужно было почитать release notes и только потом обновляться. Но опять же, сервис не критичный, можно и откатиться..
Немного менеджерского:
Пытаюсь заставить джуна написать план установки патча. Учесть это, это, сообщить этим, чтоб дернули службу на связанном сервисе, проверка работоспособности. Нет, просто "я поставлю патч" не подходит. Ощущение, что я мучаю котёнка, а всего-то хочу научить человека планировать и проводить изменения (желательно, без моего участия). И забить не могу, потому что сервис критичный. Надо бы найти ему что-то не столь критичное и кинуть одного работать, что ли, чтобы натолкнулся на "всё сломалось" и спроецировал на критичный сервис. Чувствую в себе двойные стандарты (оглянулась на поломанный и починенный ssh, вздохнула).
Другая проблема: в программе отражаются неправильные должности, поэтому ей нельзя официально пользоваться. Должности берутся из AD. Почему в AD неправильные? Так сложилось. Можно ли брать должности из 1С? Можно, но у 1с-ников расписано время на текущие задачи, можем ли мы вклиниться? Можем, давайте через 2 недели. А может, заодно и в AD будете сразу выгружать из 1С? Нет, должности длинные, надо менять схему AD, инфраструктура не хочет. И некому писать интеграцию. Но 1с-ники выгрузят diff и навесят задач на саппорт менять руками. Или инфраструктура напишет скрипт, но не факт. Может тогда нафиг пока выключим отображение должностей в софте, чтоб морально не страдали? Если будет очень надо выключим, но пока ждём. И по кругу на телефоне и ножками: начальник-> 1C-> программер-> бизнес-заказчик.
#будни
❤3👍2
Работа и алкоголь
"Админы были пьяны, меняли пароли" (с)
В честь пятницы
🍻
Когда я пришла на работу в первый день, тогдашний начальник меня отвёл в уголок и строго спросил: "Ты пьёшь?". Я как-то даже растерялась, подумала, может на запойную похожа, и осторожно сказала: "Ну, на работе нет". "Это ты зря, зря" - сказал начальник.
Сейчас мы все ужестарые взрослые, с болячками, чувством ответственности и за рулём. На работе не употребляем вообще (ну может 31 декабря кому-то шампанского нальют бокал). Я так и вне работы тоже нынче не пью алкоголь. Но были времена и была история.
Вообще, я знала, что с работой требующей концентрации, алкашка не очень сочетается. Но, например, писать текст выступления к вебинару можно было и так.
Однажды (давно, если что) мы начали что-то отмечать часа, эдак, в 3 дня. То ли командировочные к нам заканчивали командировку, то ли ещё какой повод был. А в тот период я перевозила контроллеры домена, стоящие в каждом филиале, на новое железо и на ось 2012R2 с 2012. Нам надо было поднять уровень домена, чтоб получить какие-то фичи. И вот, хм, у меня открыто три RDP с 2012 сервером и три с 2012R2. Алгоритм примерно такой:
1) на старом сервере меняю DNS
2) старый сервер понижаю
3) на старом сервере сношу службы AD DS и DNS
4) Старый сервер переименовываю
5) на старом сервере меняю ip (предварительно проверяю, что он свободный)
6) назначаю имя и ip старого сервера на новый, жду пока пропишется DNS
7) поднимаю роль на новом сервере
8) повышаю новый сервер до контроллера домена
9) жду initial replication на новом сервере
10) отписываю, что всё ок
А серверов, соответственно, три комплекта, интерфейс похож, имена похожи. И делаю я это в параллель. И тогда ещё на одном мониторе.
Ну а много ли надо для сбития концентрации для отдельно взятого женского организма.. Нет, жести не будет, домен я не угробила. Но параллельный процесс пришлось сделать последовательным, потому что в какой-то момент я уже начала повышение до КД на старом сервере, однако вовремя заметила.
Ну вот с тех пор на работе в рабочее время не употребляю) А после работы мы собираемся раз полгода-год вспомнить былые времена.
"Админы были пьяны, меняли пароли" (с)
В честь пятницы
🍻
Когда я пришла на работу в первый день, тогдашний начальник меня отвёл в уголок и строго спросил: "Ты пьёшь?". Я как-то даже растерялась, подумала, может на запойную похожа, и осторожно сказала: "Ну, на работе нет". "Это ты зря, зря" - сказал начальник.
Сейчас мы все уже
Вообще, я знала, что с работой требующей концентрации, алкашка не очень сочетается. Но, например, писать текст выступления к вебинару можно было и так.
Однажды (давно, если что) мы начали что-то отмечать часа, эдак, в 3 дня. То ли командировочные к нам заканчивали командировку, то ли ещё какой повод был. А в тот период я перевозила контроллеры домена, стоящие в каждом филиале, на новое железо и на ось 2012R2 с 2012. Нам надо было поднять уровень домена, чтоб получить какие-то фичи. И вот, хм, у меня открыто три RDP с 2012 сервером и три с 2012R2. Алгоритм примерно такой:
1) на старом сервере меняю DNS
2) старый сервер понижаю
3) на старом сервере сношу службы AD DS и DNS
4) Старый сервер переименовываю
5) на старом сервере меняю ip (предварительно проверяю, что он свободный)
6) назначаю имя и ip старого сервера на новый, жду пока пропишется DNS
7) поднимаю роль на новом сервере
8) повышаю новый сервер до контроллера домена
9) жду initial replication на новом сервере
10) отписываю, что всё ок
А серверов, соответственно, три комплекта, интерфейс похож, имена похожи. И делаю я это в параллель. И тогда ещё на одном мониторе.
Ну а много ли надо для сбития концентрации для отдельно взятого женского организма.. Нет, жести не будет, домен я не угробила. Но параллельный процесс пришлось сделать последовательным, потому что в какой-то момент я уже начала повышение до КД на старом сервере, однако вовремя заметила.
Ну вот с тех пор на работе в рабочее время не употребляю) А после работы мы собираемся раз полгода-год вспомнить былые времена.
❤2😱2
Блокировка компа
Постаралась с первых дней работы выработать привычку "попу поднял - комп заблокировал".
Ну, во-первых, враг не дремлет. Нас тут в офисе 500 человек с пропусками и просто всяких "я курьер на 2 минуты пробегу".
Во-вторых, в кабинете сидит сорок человек айтишников. Что у них на уме - не ясно. Потечёт у кого-то чердак, а у тебя тут админка от AD открыта со всеми правами или просто на рабочем столе сделают ctrl+a del - оно тебе надо? Или письмо директору/контрагенту отправит матерное "по приколу" с вашего ящика(чувство юмора у всех разное). А может reload на циске введут. Или в линухе reboot. Ну чисто поржать, случаются такие у людей выступления, зачем провоцировать 😈
Так что "выпускаешь комп из вида - заблокируй". Даже на минутку. Всегда.
И своих сотрудников этим пилю. Розыгрышей не устраиваю, но ворд открыть со словами "Враги рядом" могу :)
А вы как относитесь к своему рабочему месту?
Картинка от касперского, насколько помню
Постаралась с первых дней работы выработать привычку "попу поднял - комп заблокировал".
Ну, во-первых, враг не дремлет. Нас тут в офисе 500 человек с пропусками и просто всяких "я курьер на 2 минуты пробегу".
Во-вторых, в кабинете сидит сорок человек айтишников. Что у них на уме - не ясно. Потечёт у кого-то чердак, а у тебя тут админка от AD открыта со всеми правами или просто на рабочем столе сделают ctrl+a del - оно тебе надо? Или письмо директору/контрагенту отправит матерное "по приколу" с вашего ящика(чувство юмора у всех разное). А может reload на циске введут. Или в линухе reboot. Ну чисто поржать, случаются такие у людей выступления, зачем провоцировать 😈
Так что "выпускаешь комп из вида - заблокируй". Даже на минутку. Всегда.
И своих сотрудников этим пилю. Розыгрышей не устраиваю, но ворд открыть со словами "Враги рядом" могу :)
А вы как относитесь к своему рабочему месту?
Картинка от касперского, насколько помню
👍9
Ещё немного паранойи
Но не в последний раз
Лет десять назад у нас было ПО, которое обновляло базы методом прихода мальчика-с-флешкой. То ли Консультант+ имел такую передовую технологию, то ли ещё что аналогичное.
Приходил товарищ, говорил "я из компании К, пришёл обновлять ваши базы", его сажали за комп и он под строгим надзором что-то делал.
Оглядываясь назад, вижу, что не слишком безопасная схема, не так ли?
Принимал и надзирал за этим волшебным человекомтот кто бегал за пивом младший по званию, то есть я. А я тогда начиталась Шнайера про защиту информации и про то, что человек - самое слабое место в защите системы. Все эти "я вот тут только флешечку воткну вам антивирус обновить", а у вас р-р-раз и вся база утекла.
И тут ситуация, прямо с книжки списаная: приходит незнакомый человек, говорит "я из компании К" и рвётся к компу воткнуть флешку. До этого год стабильно ходил один и тот же сотрудник, а тут новое лицо. А ещё, молвит человеческим голосом: "я вам ххх обновлю, будет чуть дольше и надо будет ввести пароль администратора". И я такая: "Хмм, а вы можете доказать, что вы работаете в компании К? У меня вот написано, что приходит Василий Петрович и фотка есть на визитке, чего-то вы не похожи". А у него и визитки нет, и из документов только паспорт, даже завалящего пропуска с фоткой в компанию К нет. Кричит, что времени мало, к компу рвётся. То есть вообще, прямо по книжке, можно охране сдавать.
Закончилось тем, что я позвонила в компанию К, добралась до кого-то вменяемого, кто мне подтвердил личность нового сотрудника и объяснил, что предыдущий болеет (а письмом не предупредили потому что всем обычно без разницы кто там приходит и что делает). Но впечатлений и у меня, и у него осталось масса.
Были и истории, где бдительность оправдалась. Ждите в следующих сериях.
Но не в последний раз
Лет десять назад у нас было ПО, которое обновляло базы методом прихода мальчика-с-флешкой. То ли Консультант+ имел такую передовую технологию, то ли ещё что аналогичное.
Приходил товарищ, говорил "я из компании К, пришёл обновлять ваши базы", его сажали за комп и он под строгим надзором что-то делал.
Оглядываясь назад, вижу, что не слишком безопасная схема, не так ли?
Принимал и надзирал за этим волшебным человеком
И тут ситуация, прямо с книжки списаная: приходит незнакомый человек, говорит "я из компании К" и рвётся к компу воткнуть флешку. До этого год стабильно ходил один и тот же сотрудник, а тут новое лицо. А ещё, молвит человеческим голосом: "я вам ххх обновлю, будет чуть дольше и надо будет ввести пароль администратора". И я такая: "Хмм, а вы можете доказать, что вы работаете в компании К? У меня вот написано, что приходит Василий Петрович и фотка есть на визитке, чего-то вы не похожи". А у него и визитки нет, и из документов только паспорт, даже завалящего пропуска с фоткой в компанию К нет. Кричит, что времени мало, к компу рвётся. То есть вообще, прямо по книжке, можно охране сдавать.
Закончилось тем, что я позвонила в компанию К, добралась до кого-то вменяемого, кто мне подтвердил личность нового сотрудника и объяснил, что предыдущий болеет (а письмом не предупредили потому что всем обычно без разницы кто там приходит и что делает). Но впечатлений и у меня, и у него осталось масса.
Были и истории, где бдительность оправдалась. Ждите в следующих сериях.
👍8
Когда паранойя оправдалась
Случай первый, не совсем админский
Лет эдак несколько назад было несколько случаев типичной социальной инженерии. Звонит, значит, в отдел ИТ весёлый мужик. Говорит: "Здравствуйте, Наталья, да? (алё, мужик, я представилась секунду назад) Я из компании С (родственной компании, с которой у нас и правда близкие отношения), отдел ИТ, мне тут руководство поручило обновить справочную информацию, пришлите мне справочник сотрудников с городскими и мобильными телефонами, должностями".
Тут надо сделать отступление, справочниками мы такими действительно иногда обменивались и даже иногда служебные мобильные там фигурировали. Но Наташа-подозревака читала Брюса Шнайера, враг не пройдёт.
"Конечно, пришлите, пожалуйста официальный запрос входящим письмом на Генерального директора, его зарегистрируют, спустят мне и я сразу же вам пришлю!"
Мужик стал давить на всякое:
"Наталья, ну какой Генеральный, вот у вас начальник, Сергей же, да, он в курсе поручения, нам очень срочно надо, поручение моего Самого-самого начальника (называет имя), ваш Гегеральный _имя_ был на совещании вчера, давайте не будем никого напрягать, быстренько сделаем, а письмо я сразу после направлю как полагается, секретарю же, Марии, да?"
"Ок, присылайте письмо на мою почту и в копию моего начальника, если он согласует - пришлю"
"А почту не поскажете?". Тут у меня уже набат. Так как почтовый справочник у них наш подгружен и элементарно по фамилии все ищутся. Что я и сообщаю "в корпоративной почте найдете меня по фамилии".
И тут финиш:
"Наталья, у нас тут офис переезжает, большой ремонт, не все рабочие места подключили, не смогу ваш адрес найти. Вы мне пришлите на ххх@маил.ру".
Я выдавила что-то типа "извините, только на корпоративную почту", мужик пытался ещё что-то сказать, но я трубку повесила.
Во-первых, действительно такой обмен данными только согласованный и только по корпоративным каналам с защитой (у нас был настроен такой). Никакого маил.ру. Первого хватило бы, но: во-вторых, я в курсе, что у них
а) забанена вся внешняя почта в компании и
б) корпоративная почта доступна из инета, owa есть.
После краткого анализа: все имена всех упоминаемых начальников и секретарей обеих компаний можно было найти на официальных сайтах. Прям по книжке пытались заболтать знакомыми именами и срочностью, слегка запугать. Всё строго из открытых источников.
Чувак, выполняющий функции безопасника, сидел за соседним столом и следующая моя фраза была "Ща такооой чёрт самоуверенный звонил, ты не поверишь!". После рассказа я пошла ваять предупредительную рассылку по всем пользователям. И посыпался вал звонков "а вдруг им правда телефоны нужны будут, вдруг правда компания С?". Мало кто вдумчиво инструкцию прочитал 😔 Надеюсь, остальные просто не осилисли слить справочник.
Таких звонков была ещё парочка, потом всё успокоилось. Никаких официальных запросов после не поступало.
Щёлкни на картинку и посмотри моё творчество на тему ИБ))
Случай первый, не совсем админский
Лет эдак несколько назад было несколько случаев типичной социальной инженерии. Звонит, значит, в отдел ИТ весёлый мужик. Говорит: "Здравствуйте, Наталья, да? (алё, мужик, я представилась секунду назад) Я из компании С (родственной компании, с которой у нас и правда близкие отношения), отдел ИТ, мне тут руководство поручило обновить справочную информацию, пришлите мне справочник сотрудников с городскими и мобильными телефонами, должностями".
Тут надо сделать отступление, справочниками мы такими действительно иногда обменивались и даже иногда служебные мобильные там фигурировали. Но Наташа-подозревака читала Брюса Шнайера, враг не пройдёт.
"Конечно, пришлите, пожалуйста официальный запрос входящим письмом на Генерального директора, его зарегистрируют, спустят мне и я сразу же вам пришлю!"
Мужик стал давить на всякое:
"Наталья, ну какой Генеральный, вот у вас начальник, Сергей же, да, он в курсе поручения, нам очень срочно надо, поручение моего Самого-самого начальника (называет имя), ваш Гегеральный _имя_ был на совещании вчера, давайте не будем никого напрягать, быстренько сделаем, а письмо я сразу после направлю как полагается, секретарю же, Марии, да?"
"Ок, присылайте письмо на мою почту и в копию моего начальника, если он согласует - пришлю"
"А почту не поскажете?". Тут у меня уже набат. Так как почтовый справочник у них наш подгружен и элементарно по фамилии все ищутся. Что я и сообщаю "в корпоративной почте найдете меня по фамилии".
И тут финиш:
"Наталья, у нас тут офис переезжает, большой ремонт, не все рабочие места подключили, не смогу ваш адрес найти. Вы мне пришлите на ххх@маил.ру".
Я выдавила что-то типа "извините, только на корпоративную почту", мужик пытался ещё что-то сказать, но я трубку повесила.
Во-первых, действительно такой обмен данными только согласованный и только по корпоративным каналам с защитой (у нас был настроен такой). Никакого маил.ру. Первого хватило бы, но: во-вторых, я в курсе, что у них
а) забанена вся внешняя почта в компании и
б) корпоративная почта доступна из инета, owa есть.
После краткого анализа: все имена всех упоминаемых начальников и секретарей обеих компаний можно было найти на официальных сайтах. Прям по книжке пытались заболтать знакомыми именами и срочностью, слегка запугать. Всё строго из открытых источников.
Чувак, выполняющий функции безопасника, сидел за соседним столом и следующая моя фраза была "Ща такооой чёрт самоуверенный звонил, ты не поверишь!". После рассказа я пошла ваять предупредительную рассылку по всем пользователям. И посыпался вал звонков "а вдруг им правда телефоны нужны будут, вдруг правда компания С?". Мало кто вдумчиво инструкцию прочитал 😔 Надеюсь, остальные просто не осилисли слить справочник.
Таких звонков была ещё парочка, потом всё успокоилось. Никаких официальных запросов после не поступало.
Щёлкни на картинку и посмотри моё творчество на тему ИБ))
👍6🔥1
Инструкции
Мне тут безопасник настоятельно посоветовал не рассказывать о методах социальной инженерии, так что вы можете прочитать про них самостоятельно и смоделировать свои ситуации))
Пожалуй, свернём на этом недельку инфобеза
Давайте, что ли, поговорим про инструкции.
В какой-то момент меня задолбало рассылать персонально каждому инструкцию или указывать, где она лежит и я решила завести справочную систему на работе. И все такие "wiki, давай wiki", а я тогда что подумала: ну кто кроме меня эти инструкции пишет? Примерно никто. Ну и зачем мне вики, переживать что кто-то где-то напишет неправильно, возиться с markup language. И я завела HelpNDoc. Классная, кстати, вещь, чтоб вести в одно рыло, рекомендую. И в pdf умеет сразу выгружать всю справку, да хоть в ePub.
Жила она долго, а потом мы как-то приросли народом, унификация опять же, другие службы заведи себе wiki, ну и мы тоже пошли по этому пути. Сначала, лет 5 назад, завели одну вики систему, года полтора как переехали на другую. Всем объявили: есть вики, любой может написать!
Ну и, хм, инструкции всё так же пишу я и иногда мои сотрудники (если я грозно стою с палкой рядом). Только разметка с каждым обновлением уползает к хренам, потом в исходник страшно смотреть. И писать неудобно, прямо скажем, есть вики и получше.
Нужно ли писать инструкции? Да, да и ещё раз да! Моей инструкции по настройке ftp 11 лет и до сих пор туда поглядываю. Вы и не вспомните через год что там где настраивали и подкручивали, чтоб оно работало. Нужно это в первую очередь вам:
а) чтоб самому потом вспомнить
б) чтоб кого-то ткнуть в инструкцию и снять с себя часть работы (или чтоб передать дела)
в) чтоб просто у себя в голове структурировать информацию и что-нибудь прикольное понять
Однажды мне переслали мой же пост с пикабу со словами: вот же классная инструкция, а ты жаловалась, что ничего на эту тему нет. Было приятно)
Я пишу мануалы нескольких видов:
1) Для себя или того, кто в этой теме хорошо понимает. Минимум воды, перечислены основные действия и подводные камни
2) Для адекватных админов: достаточно подробно, но в надежде, что у человека есть базовые понимания как этим пользоваться
3) Для всех админов: то, что рождается из п.2 по результатам выполнения таких инструкций. Люди разные, иногда появляются этапы вроде: "перед попыткой включить сервер, воткнуть шнур питания одним концом в сервер, а другим в электрическую розетку".
Где-то в истории пылится инструкция в шести картинках, которую послали в ответ на вопрос "у прибора не дотягивается шнур до розетки, что делать?"
4) Чтоб передать конкретный процесс кому-то: подробность зависит от уровня того, кому передаю.
5) Для пользователей: минимум условий "если то, то сделайте", максимум картинок, выделение жирным, красным, зелёным и прочими цветами.
Также я автор вводных инструкций по типу "ааа, куда я попал вообще, мне не передали дела, я новенький". Не знаю уж, насколько они мне удаются, но лучше, чем их отсутствие 😊
Вот тебе делать нехрен? Я думаю, это важная часть работы, даже если кто-то так не думает.
Как выстроить классную справочную систему, которую все будут радостно вести, актуализировать (и которая будет правильно структурирована), я всё ещё не знаю. Заниматься графоманией людей обычно не вставляет. И все мои "бу-бу-бу, как обновлять/чинить финтифлюшку если ты в отпуске, напиши хоть пару строк" падают вникуда, но я не прекращаю попыток))
Есть вариант с тем, что система сама себя документирует, эдакий DevOps подход. Но это же не включит в себя реакцию на инциденты, методику диагностики и всё такое. Опять же, к винде не очень применимо, хоть она и переходит на .conf файлы (если я ошибаюсь, ткните, плиз, в пару статей на тему).
Если есть положительный опыт внедрения подобных систем, поделитесь что ли
Давайте, что ли, поговорим про инструкции.
В какой-то момент меня задолбало рассылать персонально каждому инструкцию или указывать, где она лежит и я решила завести справочную систему на работе. И все такие "wiki, давай wiki", а я тогда что подумала: ну кто кроме меня эти инструкции пишет? Примерно никто. Ну и зачем мне вики, переживать что кто-то где-то напишет неправильно, возиться с markup language. И я завела HelpNDoc. Классная, кстати, вещь, чтоб вести в одно рыло, рекомендую. И в pdf умеет сразу выгружать всю справку, да хоть в ePub.
Жила она долго, а потом мы как-то приросли народом, унификация опять же, другие службы заведи себе wiki, ну и мы тоже пошли по этому пути. Сначала, лет 5 назад, завели одну вики систему, года полтора как переехали на другую. Всем объявили: есть вики, любой может написать!
Ну и, хм, инструкции всё так же пишу я и иногда мои сотрудники (если я грозно стою с палкой рядом). Только разметка с каждым обновлением уползает к хренам, потом в исходник страшно смотреть. И писать неудобно, прямо скажем, есть вики и получше.
Нужно ли писать инструкции? Да, да и ещё раз да! Моей инструкции по настройке ftp 11 лет и до сих пор туда поглядываю. Вы и не вспомните через год что там где настраивали и подкручивали, чтоб оно работало. Нужно это в первую очередь вам:
а) чтоб самому потом вспомнить
б) чтоб кого-то ткнуть в инструкцию и снять с себя часть работы (или чтоб передать дела)
в) чтоб просто у себя в голове структурировать информацию и что-нибудь прикольное понять
Однажды мне переслали мой же пост с пикабу со словами: вот же классная инструкция, а ты жаловалась, что ничего на эту тему нет. Было приятно)
Я пишу мануалы нескольких видов:
1) Для себя или того, кто в этой теме хорошо понимает. Минимум воды, перечислены основные действия и подводные камни
2) Для адекватных админов: достаточно подробно, но в надежде, что у человека есть базовые понимания как этим пользоваться
3) Для всех админов: то, что рождается из п.2 по результатам выполнения таких инструкций. Люди разные, иногда появляются этапы вроде: "перед попыткой включить сервер, воткнуть шнур питания одним концом в сервер, а другим в электрическую розетку".
Где-то в истории пылится инструкция в шести картинках, которую послали в ответ на вопрос "у прибора не дотягивается шнур до розетки, что делать?"
4) Чтоб передать конкретный процесс кому-то: подробность зависит от уровня того, кому передаю.
5) Для пользователей: минимум условий "если то, то сделайте", максимум картинок, выделение жирным, красным, зелёным и прочими цветами.
Также я автор вводных инструкций по типу "ааа, куда я попал вообще, мне не передали дела, я новенький". Не знаю уж, насколько они мне удаются, но лучше, чем их отсутствие 😊
Вот тебе делать нехрен? Я думаю, это важная часть работы, даже если кто-то так не думает.
Как выстроить классную справочную систему, которую все будут радостно вести, актуализировать (и которая будет правильно структурирована), я всё ещё не знаю. Заниматься графоманией людей обычно не вставляет. И все мои "бу-бу-бу, как обновлять/чинить финтифлюшку если ты в отпуске, напиши хоть пару строк" падают вникуда, но я не прекращаю попыток))
Есть вариант с тем, что система сама себя документирует, эдакий DevOps подход. Но это же не включит в себя реакцию на инциденты, методику диагностики и всё такое. Опять же, к винде не очень применимо, хоть она и переходит на .conf файлы (если я ошибаюсь, ткните, плиз, в пару статей на тему).
Если есть положительный опыт внедрения подобных систем, поделитесь что ли
👍2
Рассказ про прикольную систему образования, которая не выжила
Уж на что-что, а на образование я пожаловаться не могу, оно у меня профильное - айтишное. Система была странная, но интересная, вероятно, продвигал её один энтузиаст из руководства кафедры.
Заключалась в следующем:
1) Даётся база. Да, старые надёжные алгоритмы и pascal. Как хранится int. Как выглядит файл. Простые лабы. Таненбаум про операционные системы. Чтоб вообще начать понимать что происходит.
2) по возможности привлекаются работающие специалисты для преподавания: сети, базы данных, этапы разработки. Они передают прям живые знания
3) все после 4 курса начинают преподавать более младшим. Чем интересуешься - тому и учишь. Устроился стажёром - расскажи что узнал. Некоторых выпускников вставляет педагогика и они остаются ещё год-два-три вести лекции, работая при этом где-то. Во-первых, чтоб кого-то учить, надо досконально разобраться самому. Во-вторых, тянется всё модное и свежее
4) привлекаются бывшие выпускники провести курс или лекцию. Тестирование, графика, регулярки perl, python, Qt, админство linux, "как выступать перед публикой", "как работает жидкокристаллический экран", "как работает процессор intel", "как мы сканируемсиськи грудь на томографе"
5) языки программирования и их дополнения в формате "семестр-курс". Тогда (2007-2011) это были Delphi, C (+ lin/win api), C#, C++, MFC (простихосподи, какая хрень), COM (не можешь заснуть - открой книжку по СОМ), Qt, ещё что-то было. На каждом пишем какой-нить проект, его надо выдумать и не забыть написать документацию. Как только прошли клиент-серверные модели, сокеты изучили - так сразу должен быть клиент и сервер на разных языках писаный. Как прошли многопоточноть - должно быть много потоков и чтоб за ресурсы соревновались обязательно. Разделяемая память, семафоры, мьютексы, именованные каналы, вот это всё. И чтоб пользовательский интерфейс не фризился, и чтоб отрисовка не моргала. Один проект на 2-4 студента - обговори протоколы взаимодействия модулей, не подерись в команде.
6) поощрялись нестандартные выполнения заданий и любая движуха в рамках ИТ
7) Сверху отполировать математикой. Матрицы? Считаем матрицы. Криптография? Вычисления в полях Галуа, а давайте напишем AES, а сделайте мне цифровую подпись и чтоб шифрование выбирать. Ряды. Что-там с диффурами и рядами было, я уже не помню. Графы? Значит строим обходы графов. Ну и т.д.
В результате получались более-менее актуальные знания по (тем) современным веяниям, живые практические знания от специалистов, всё это с классической алгоритмической и математической базой. Да, всё по верхам, но углубиться можно было в любую сторону - хоть фундаментальная математика, хоть роботостроение с ардуинками, хоть фронтэнд, хоть бэк, хоть сети, хоть администрирование. Как только появлялись новые популярные штуки - их начинали включать в программу. Предмет при этом мог называться как угодно, самый популярный вариант был "практикум на ЭВМ". За нами младшим уже читали питон глубоко, Го'шечку тоже вроде читали после нас, я уверена, что вские куберы-докеры тоже вовремя подоспели.
Схема выстраивала чудовищно крепкие вертикальные связи. То есть, студенты с первого по шестой курс общались очень плотно. Плюс навык работы на публику какой-никакой тоже все приобретали.
Не исключаем все сопутствующие высшему образованию предметы: философия, история, физика, анализ и прочее.
Схема держалась лет, наверное, 18-20. К тому моменту как я училась, она стала самоподдерживающейся в плане потока передачи знаний. Не знаю, каков был старт (как учили первых студентов) - не застала. Но держалась она на людях и общем некотором распиздяйстве. Попробуй сейчас скажи, что у вас в пятницу официально 1 пара "практикум на ЭВМ", а неофициально три, после чего коллоквиум до ночи и чтоб сдать зачёт, надо сдать три предмета трём разным людям. Ну это мой вариант, почему всё развалилось, может и иначе было.
Не без недостатков, но, оглядываясь назад и сравнивая с рассказами других, отличная была система!
Уж на что-что, а на образование я пожаловаться не могу, оно у меня профильное - айтишное. Система была странная, но интересная, вероятно, продвигал её один энтузиаст из руководства кафедры.
Заключалась в следующем:
1) Даётся база. Да, старые надёжные алгоритмы и pascal. Как хранится int. Как выглядит файл. Простые лабы. Таненбаум про операционные системы. Чтоб вообще начать понимать что происходит.
2) по возможности привлекаются работающие специалисты для преподавания: сети, базы данных, этапы разработки. Они передают прям живые знания
3) все после 4 курса начинают преподавать более младшим. Чем интересуешься - тому и учишь. Устроился стажёром - расскажи что узнал. Некоторых выпускников вставляет педагогика и они остаются ещё год-два-три вести лекции, работая при этом где-то. Во-первых, чтоб кого-то учить, надо досконально разобраться самому. Во-вторых, тянется всё модное и свежее
4) привлекаются бывшие выпускники провести курс или лекцию. Тестирование, графика, регулярки perl, python, Qt, админство linux, "как выступать перед публикой", "как работает жидкокристаллический экран", "как работает процессор intel", "как мы сканируем
5) языки программирования и их дополнения в формате "семестр-курс". Тогда (2007-2011) это были Delphi, C (+ lin/win api), C#, C++, MFC (простихосподи, какая хрень), COM (не можешь заснуть - открой книжку по СОМ), Qt, ещё что-то было. На каждом пишем какой-нить проект, его надо выдумать и не забыть написать документацию. Как только прошли клиент-серверные модели, сокеты изучили - так сразу должен быть клиент и сервер на разных языках писаный. Как прошли многопоточноть - должно быть много потоков и чтоб за ресурсы соревновались обязательно. Разделяемая память, семафоры, мьютексы, именованные каналы, вот это всё. И чтоб пользовательский интерфейс не фризился, и чтоб отрисовка не моргала. Один проект на 2-4 студента - обговори протоколы взаимодействия модулей, не подерись в команде.
6) поощрялись нестандартные выполнения заданий и любая движуха в рамках ИТ
7) Сверху отполировать математикой. Матрицы? Считаем матрицы. Криптография? Вычисления в полях Галуа, а давайте напишем AES, а сделайте мне цифровую подпись и чтоб шифрование выбирать. Ряды. Что-там с диффурами и рядами было, я уже не помню. Графы? Значит строим обходы графов. Ну и т.д.
В результате получались более-менее актуальные знания по (тем) современным веяниям, живые практические знания от специалистов, всё это с классической алгоритмической и математической базой. Да, всё по верхам, но углубиться можно было в любую сторону - хоть фундаментальная математика, хоть роботостроение с ардуинками, хоть фронтэнд, хоть бэк, хоть сети, хоть администрирование. Как только появлялись новые популярные штуки - их начинали включать в программу. Предмет при этом мог называться как угодно, самый популярный вариант был "практикум на ЭВМ". За нами младшим уже читали питон глубоко, Го'шечку тоже вроде читали после нас, я уверена, что вские куберы-докеры тоже вовремя подоспели.
Схема выстраивала чудовищно крепкие вертикальные связи. То есть, студенты с первого по шестой курс общались очень плотно. Плюс навык работы на публику какой-никакой тоже все приобретали.
Не исключаем все сопутствующие высшему образованию предметы: философия, история, физика, анализ и прочее.
Схема держалась лет, наверное, 18-20. К тому моменту как я училась, она стала самоподдерживающейся в плане потока передачи знаний. Не знаю, каков был старт (как учили первых студентов) - не застала. Но держалась она на людях и общем некотором распиздяйстве. Попробуй сейчас скажи, что у вас в пятницу официально 1 пара "практикум на ЭВМ", а неофициально три, после чего коллоквиум до ночи и чтоб сдать зачёт, надо сдать три предмета трём разным людям. Ну это мой вариант, почему всё развалилось, может и иначе было.
Не без недостатков, но, оглядываясь назад и сравнивая с рассказами других, отличная была система!
👏2
Когда что-то случается
И немножко про деньги
Внезапно, когда в компании много офисов, отделений и т.д. всегда что-то случается. Когда вы видите один офис, то понятно, что у вас раз в год отключат электричество в будний день и это будет событие. А в другой год кабель перекопают к провайдеру и это тоже будет событие.
Когда ваше количество офисов перевалит за 52 (количество недель в году), то со стороны админа всей сети, вы будете наблюдать такие "события" в среднем раз в неделю. А если офисов так и будет прирастать, то и чаще. Это просто статистика. Да, в эту неделю плановое отключение электричества в Х, в следующую наводнение в Y, потом прорыв канализации над серверной в Z, у D перекопают ковшом кабели от обоих провайдеров, у N пропадет спутниковый интернет из-за бури, а в K электроподстанция сдохнет от обрыва проводов под снегом. Потом у Ростелеком будут проблемы с доступностью всего Дальнего Востока, а РКН в субботу рубанёт на час весь IPSec.
И ничего страшного от этого не случится. Где-то подхватится резервный провайдер, где-то можнно заранее перераспределить работу. А где-то всё внезапно встанет. Если у вас не больница или ракетная часть, и не станция перекачивания говна из канализации, то есть не критичная для жизни инфраструктура, то наблюдается следующая, страшная для юных умов штука:
Иногда делать отказоустойчивую инфраструктуру нерентабельно. Вот так просто, вы затратите на инфраструктуру и её обслуживание больше бабла, чем потеряете при простое пару раз в год на сутки в течение 15 лет, например. (тут надо аккуратнно считать деньги, например, есть репутационные риски, которые тоже выражаются в деньгах).
Поэтому вот иметь ups на 5 минут на случай "мигнуло электричество" рентабельно, а иметь стойку ups на два часа работы и дизель-генератор уже не очень.
Или наоборот, вы будете терять килограммы денег в минуту и дизель-генератор со всем его обслуживанием окупится за пару минут, бывает и так и так.
В общем, мысли две:
1) Когда в большой сети что-то постоянно случается - это нормально. Главное, чтоб в целом не падало. Не стоит страдать от неидеальности мира и незелёного заббикса.
2) Когда вы, просветленный после митапа по построению отказоустойчивой инфраструктуры, приходите на работу и хотите сделать "как в лучших домах" - попробуйте посчитать в деньгах разные развития событий и не расстраивайтесь, если три четверти изменений принято не будет. Врочем, это не значит, что к идеалу не стоит стремиться доступными средствами.
Картинка Васи Ложкина
И немножко про деньги
Внезапно, когда в компании много офисов, отделений и т.д. всегда что-то случается. Когда вы видите один офис, то понятно, что у вас раз в год отключат электричество в будний день и это будет событие. А в другой год кабель перекопают к провайдеру и это тоже будет событие.
Когда ваше количество офисов перевалит за 52 (количество недель в году), то со стороны админа всей сети, вы будете наблюдать такие "события" в среднем раз в неделю. А если офисов так и будет прирастать, то и чаще. Это просто статистика. Да, в эту неделю плановое отключение электричества в Х, в следующую наводнение в Y, потом прорыв канализации над серверной в Z, у D перекопают ковшом кабели от обоих провайдеров, у N пропадет спутниковый интернет из-за бури, а в K электроподстанция сдохнет от обрыва проводов под снегом. Потом у Ростелеком будут проблемы с доступностью всего Дальнего Востока, а РКН в субботу рубанёт на час весь IPSec.
И ничего страшного от этого не случится. Где-то подхватится резервный провайдер, где-то можнно заранее перераспределить работу. А где-то всё внезапно встанет. Если у вас не больница или ракетная часть, и не станция перекачивания говна из канализации, то есть не критичная для жизни инфраструктура, то наблюдается следующая, страшная для юных умов штука:
Иногда делать отказоустойчивую инфраструктуру нерентабельно. Вот так просто, вы затратите на инфраструктуру и её обслуживание больше бабла, чем потеряете при простое пару раз в год на сутки в течение 15 лет, например. (тут надо аккуратнно считать деньги, например, есть репутационные риски, которые тоже выражаются в деньгах).
Поэтому вот иметь ups на 5 минут на случай "мигнуло электричество" рентабельно, а иметь стойку ups на два часа работы и дизель-генератор уже не очень.
Или наоборот, вы будете терять килограммы денег в минуту и дизель-генератор со всем его обслуживанием окупится за пару минут, бывает и так и так.
В общем, мысли две:
1) Когда в большой сети что-то постоянно случается - это нормально. Главное, чтоб в целом не падало. Не стоит страдать от неидеальности мира и незелёного заббикса.
2) Когда вы, просветленный после митапа по построению отказоустойчивой инфраструктуры, приходите на работу и хотите сделать "как в лучших домах" - попробуйте посчитать в деньгах разные развития событий и не расстраивайтесь, если три четверти изменений принято не будет. Врочем, это не значит, что к идеалу не стоит стремиться доступными средствами.
Картинка Васи Ложкина
👍4
Немножко про циски и минутка философии
Был случай в одной компании, когда нужно было нежно забрать управление cisco-железками.
Компания некоторым образом решила разделиться административно на две части и так получилось, что в одной части оставался сервер Tacacs, а в другой железки. Куда делись айтишники, управляющие тем и другим, история умалчивает. Был чей-то логин-пароль с tacacs, была ниточка до него и собственно всё. Задача была забрать управление, пока есть эта зыбкая связь. Чтоб когда ниточка или tacacs исчезнут - не остаться с черными ящиками вместо управляемых железок.
Конечно, при наличии физического доступа к цискам и консольного кабеля управление забирается в любом (ладно, почти в любом) случае. Но желающих посещать с консольным кабелем несколько географически отдаленных точек отчего-то не наблюдалось.
Сейчас я думаю, что проще было поднять свой tacacs и переключиться на него)
Дальше никакой магии. Пограничные железки были нормальными маршрутизаторами и с них начали забирать управление. Они единственные имели на себе режим отката и это стало спасением.
"configure terminal revert timer x" надёжно нас поддерживал, пока я подбирала такое сочетание параметров aaa, чтоб меня не посылало нахер при попытке сказать conf t (я в во всех опциях aaa и тогда не разбиралась, да и сейчас не так чтобы очень).
Потом нужно было сделать так, чтоб на всех остальных железках, не имеющих таких механизмов отката, доступ не исчез в процессе (кстати, на cisco asa если кто что знает в плане безопсного применения конфига - подскажите, просвещусь).
Да, всегда есть живительный ребут. Но ребутаются циски долго, а большие циски очень долго. И в некоторых местах они не имели, ммм, логического дублирования. Ну типа физически железки две, но вот тебе единый control plane. В целом, план "Б" в виде ребута был, но пользоваться им не хотелось. Так что мы на тех пограничных железках гасили в null маршруты в сторону сервера авторизации и смотрели что получилось на остальных железках. Попали-не попали. Права на изменение конфига, соответственно, при этом есть или нет. В общем, было весело и страшно, потому что опыта было по нулям 😅
И да, не верьте утверждению "если у вас есть сессия с правами, то что бы вы ни меняли она останется" - это не так, было и такое, что выкидывало из сессии и сразу писало authorization failed.
Минутка философии.
Я вообще часто пишу "сейчас я думаю, что лучше было бы вот так". Я постоянно узнаю что-то для себя новое. Значит ли это, что тогда не нужно было действовать не имея сегодняшних знаний? Конечно нет! Результат обычно достигнут. Возможно, не оптимально, не по лучшим стандартам, не так как это сделал бы гуру, за время в 15 раз большее, чем этому гуру бы понадобилось. Не страшно. Каждый раз, углубляясь в какую-то айтишную тему, я начинаю понимать, сколько всего я ещё не знаю.
Делайте то, что можете
так, как можете,
теми инструментами, что вам доступны.
Это нормально. Никто не учится до состояния гуру, а потом уже идёт работать. Более того, никакая учёба не даст вам тех извращённых задач, которые подкидывает реальность.
А минутку философии продолжим в одной из следующих серий, тут ещё есть что сказать.
Хотела бы я, чтобы мне это рассказали в школе..
Был случай в одной компании, когда нужно было нежно забрать управление cisco-железками.
Компания некоторым образом решила разделиться административно на две части и так получилось, что в одной части оставался сервер Tacacs, а в другой железки. Куда делись айтишники, управляющие тем и другим, история умалчивает. Был чей-то логин-пароль с tacacs, была ниточка до него и собственно всё. Задача была забрать управление, пока есть эта зыбкая связь. Чтоб когда ниточка или tacacs исчезнут - не остаться с черными ящиками вместо управляемых железок.
Конечно, при наличии физического доступа к цискам и консольного кабеля управление забирается в любом (ладно, почти в любом) случае. Но желающих посещать с консольным кабелем несколько географически отдаленных точек отчего-то не наблюдалось.
Сейчас я думаю, что проще было поднять свой tacacs и переключиться на него)
Дальше никакой магии. Пограничные железки были нормальными маршрутизаторами и с них начали забирать управление. Они единственные имели на себе режим отката и это стало спасением.
"configure terminal revert timer x" надёжно нас поддерживал, пока я подбирала такое сочетание параметров aaa, чтоб меня не посылало нахер при попытке сказать conf t (я в во всех опциях aaa и тогда не разбиралась, да и сейчас не так чтобы очень).
Потом нужно было сделать так, чтоб на всех остальных железках, не имеющих таких механизмов отката, доступ не исчез в процессе (кстати, на cisco asa если кто что знает в плане безопсного применения конфига - подскажите, просвещусь).
Да, всегда есть живительный ребут. Но ребутаются циски долго, а большие циски очень долго. И в некоторых местах они не имели, ммм, логического дублирования. Ну типа физически железки две, но вот тебе единый control plane. В целом, план "Б" в виде ребута был, но пользоваться им не хотелось. Так что мы на тех пограничных железках гасили в null маршруты в сторону сервера авторизации и смотрели что получилось на остальных железках. Попали-не попали. Права на изменение конфига, соответственно, при этом есть или нет. В общем, было весело и страшно, потому что опыта было по нулям 😅
И да, не верьте утверждению "если у вас есть сессия с правами, то что бы вы ни меняли она останется" - это не так, было и такое, что выкидывало из сессии и сразу писало authorization failed.
Минутка философии.
Я вообще часто пишу "сейчас я думаю, что лучше было бы вот так". Я постоянно узнаю что-то для себя новое. Значит ли это, что тогда не нужно было действовать не имея сегодняшних знаний? Конечно нет! Результат обычно достигнут. Возможно, не оптимально, не по лучшим стандартам, не так как это сделал бы гуру, за время в 15 раз большее, чем этому гуру бы понадобилось. Не страшно. Каждый раз, углубляясь в какую-то айтишную тему, я начинаю понимать, сколько всего я ещё не знаю.
Делайте то, что можете
так, как можете,
теми инструментами, что вам доступны.
Это нормально. Никто не учится до состояния гуру, а потом уже идёт работать. Более того, никакая учёба не даст вам тех извращённых задач, которые подкидывает реальность.
А минутку философии продолжим в одной из следующих серий, тут ещё есть что сказать.
Хотела бы я, чтобы мне это рассказали в школе..
👍8
Помощь по личным вопросам
Наверное, ко всем админам приходят на работе с личными вопросами. Это не сильно зависит от того эникейщик вы или руководитель отдела - на каждом уровне у вас будет свой круг общения в компании, который будет считать вас ТЫЖ-айтишником. Схемы поведения в этом случае есть разные. Если вы простой сотрудник, то:
Можно отгородиться запросом денег (и в зависимости от настойчивости пользователя: либо отвязаться, либо монетизировать помощь).
Можно отгородиться "не умею". Да, вот сервер настраивать умею, а приставку выбирать для сына не умею. И лечить винду от вирусов тоже.
Можно проявить альтруизм и всем помогать за конфетку - тогда сядут на шею. Но и любить тоже будут, возможно вам это важно. А также будут иметь мозг по каждой неисправности после вашей помощи.
В идеальном мире, конечно же, надо выставлять жесткие границы. В реальном мире, во-первых, отказы работают до некоторого уровня "топовости" сотрудника, который к вам придёт. А во-вторых, иногда по мелочи (именно немного и иногда) помогать обычным сотрудникам по личным вопросам от вас не убудет, зато всякие внутренние взаимодействия будут идти легче. Мы не в идеальном мире, тут есть человеческий фактор. Вам тоже не обязаны подсказывать как лучше сформулировать служебку, рассказать, что можно сделать внеочередной заказ на канцелярию, первым уведомить о возможности пройти обучение и т.д.
Отказывать, в свою очередь, стоит культурно и вежливо, типа
"Иван Иваныч, я вечерами учусь всё время, куда мне разбираться в игровых приставках, я могу глянуть рейтинг одним глазком, но ничего не гарантирую, сам не пользовался".
"Мария Ивановна, я же не могу втыкать ваш зараженный ноутбук в сеть предприятия, можете подкинуть мне домой, я в толкучке метро боюсь раздавить. Там посмотрю, но у меня очень загруженная неделя на работе, может быть в течение месяца. И не гарантирую сохранение данных, всё же не мой профиль. Но вот визитка проверенного центра, они справятся быстрее."
Если вы руководитель, то стоит спросить сотрудников (вдруг кто чувствует в себе великого чинителя от вирусов, любит паять за денежку или горит желанием всем рассказать про х-box). Главное, чтоб работе не вредили эти дополнительные запросы. А если таких любителей не найдется, лучше всего соласться на то, как вы своих сотрудников день и ночь эксплуатируете и они просителям помочь не смогут потому что работают, а вечером думают о работе и даже сны видят о работе. Только вежливо, чтоб это не было прямым посылом в дальние дали. Если же просьба лично к вам, то это уже запросы, опять же, "топовых" сотрудников. Такие просьбы, по опыту, проходят в рамках работы даже не номинально и, соответсвенно, выполняются силами отдела в рабочее время.
Все эти советы "просто скажите, что это не ваша работа" тоже работают, но комфорта в коллективе не добавляют. Тут уж каждый сам выбирает: формализм или человеческие отношения. На мой взгляд, стоит балансировать и не отказываться от человеческого взаимодействия.
Наверное, ко всем админам приходят на работе с личными вопросами. Это не сильно зависит от того эникейщик вы или руководитель отдела - на каждом уровне у вас будет свой круг общения в компании, который будет считать вас ТЫЖ-айтишником. Схемы поведения в этом случае есть разные. Если вы простой сотрудник, то:
Можно отгородиться запросом денег (и в зависимости от настойчивости пользователя: либо отвязаться, либо монетизировать помощь).
Можно отгородиться "не умею". Да, вот сервер настраивать умею, а приставку выбирать для сына не умею. И лечить винду от вирусов тоже.
Можно проявить альтруизм и всем помогать за конфетку - тогда сядут на шею. Но и любить тоже будут, возможно вам это важно. А также будут иметь мозг по каждой неисправности после вашей помощи.
В идеальном мире, конечно же, надо выставлять жесткие границы. В реальном мире, во-первых, отказы работают до некоторого уровня "топовости" сотрудника, который к вам придёт. А во-вторых, иногда по мелочи (именно немного и иногда) помогать обычным сотрудникам по личным вопросам от вас не убудет, зато всякие внутренние взаимодействия будут идти легче. Мы не в идеальном мире, тут есть человеческий фактор. Вам тоже не обязаны подсказывать как лучше сформулировать служебку, рассказать, что можно сделать внеочередной заказ на канцелярию, первым уведомить о возможности пройти обучение и т.д.
Отказывать, в свою очередь, стоит культурно и вежливо, типа
"Иван Иваныч, я вечерами учусь всё время, куда мне разбираться в игровых приставках, я могу глянуть рейтинг одним глазком, но ничего не гарантирую, сам не пользовался".
"Мария Ивановна, я же не могу втыкать ваш зараженный ноутбук в сеть предприятия, можете подкинуть мне домой, я в толкучке метро боюсь раздавить. Там посмотрю, но у меня очень загруженная неделя на работе, может быть в течение месяца. И не гарантирую сохранение данных, всё же не мой профиль. Но вот визитка проверенного центра, они справятся быстрее."
Если вы руководитель, то стоит спросить сотрудников (вдруг кто чувствует в себе великого чинителя от вирусов, любит паять за денежку или горит желанием всем рассказать про х-box). Главное, чтоб работе не вредили эти дополнительные запросы. А если таких любителей не найдется, лучше всего соласться на то, как вы своих сотрудников день и ночь эксплуатируете и они просителям помочь не смогут потому что работают, а вечером думают о работе и даже сны видят о работе. Только вежливо, чтоб это не было прямым посылом в дальние дали. Если же просьба лично к вам, то это уже запросы, опять же, "топовых" сотрудников. Такие просьбы, по опыту, проходят в рамках работы даже не номинально и, соответсвенно, выполняются силами отдела в рабочее время.
Все эти советы "просто скажите, что это не ваша работа" тоже работают, но комфорта в коллективе не добавляют. Тут уж каждый сам выбирает: формализм или человеческие отношения. На мой взгляд, стоит балансировать и не отказываться от человеческого взаимодействия.
👏6
Микротик, частное мнение
Инетресно, есть ли более противоречивые железки, чем микротики? Исключительное поделие латвийского гения. Я с ними работала одно время очень плотно (пару лет) и потому выскажу своё видение.
Давайте, что ли, сначала с плюсов:
Он умеет если не всё, то многое, и при этом дешёвый (был). До санкций вы могли приобрести пару железок, умеющих BGP и MPLS, дешевле, чем книжку Олиферов по сетям.
Исключительная гибкость. Кажется, если вы придумаете самую странную задачу, её уже пытались реализовать на микротиках.
Огромное коммьюнити, которое объяснит вам как сделать любое извращение.
Умеренная надёжность и умеренная производительность. Не циска? Ну так посмотри на ценник. Дырки? Зато регулярные обновления. Виснет? Выброси и купи новый.
Скромный ценник на очное обучение. До санкций курс стоил в 5 раз дешевле cisco, а какая в принципе разница на чём пытаться въехать в OSPF и BGP. И микротик в подарок 🎁
Теперь по минусам:
Ужасный, ублюдский, отвратительный интерфейс. Это, конечно, личное мнение. Причём я умею его админить, но радости мне это не доставляет.
К сожалению, те, для кого интерфейс микротика стал первой серьёзной жезезкой, очень плохо переучиваются на что-то адекватное. Опять же, личное наблюдение на нерепрезентативной выборке.
Чтобы воспользоваться плюсами нужны прямые руки и немного знаний с капелькой мозгов. Не имея этого, скорее навредите своей сети.
Стабильная работа недорогих железок на больших объёмах? Скорее нет, чем да. Из 60 закупленных 4 сдохли в течение года.
То есть итого:
Для малого бизнеса? Конечно!
Для извращений? Несомненно!
Чтобы заткнуть внезапную дырку, где нужен NAT и ACL? Да! Возьми с полкипирожок микротик.
Для тестов и дебага сетевых проблем? Да, во многих случаях подойдёт.
Для обучения? Скорее да, чем нет. Но лучше не первым устройством.
Для массового домашнего использования? Нет.
Для эникейщика без знаний? Нет.
Для эникейщика со знаниями? Да.
Для массового кровавого энтерпрайза? Нет.
Для удовольствия? Кому как.
Ну и как обычно, это инструмент и он хорош для своих, подходящих ему задач.
Инетресно, есть ли более противоречивые железки, чем микротики? Исключительное поделие латвийского гения. Я с ними работала одно время очень плотно (пару лет) и потому выскажу своё видение.
Давайте, что ли, сначала с плюсов:
Он умеет если не всё, то многое, и при этом дешёвый (был). До санкций вы могли приобрести пару железок, умеющих BGP и MPLS, дешевле, чем книжку Олиферов по сетям.
Исключительная гибкость. Кажется, если вы придумаете самую странную задачу, её уже пытались реализовать на микротиках.
Огромное коммьюнити, которое объяснит вам как сделать любое извращение.
Умеренная надёжность и умеренная производительность. Не циска? Ну так посмотри на ценник. Дырки? Зато регулярные обновления. Виснет? Выброси и купи новый.
Скромный ценник на очное обучение. До санкций курс стоил в 5 раз дешевле cisco, а какая в принципе разница на чём пытаться въехать в OSPF и BGP. И микротик в подарок 🎁
Теперь по минусам:
Ужасный, ублюдский, отвратительный интерфейс. Это, конечно, личное мнение. Причём я умею его админить, но радости мне это не доставляет.
К сожалению, те, для кого интерфейс микротика стал первой серьёзной жезезкой, очень плохо переучиваются на что-то адекватное. Опять же, личное наблюдение на нерепрезентативной выборке.
Чтобы воспользоваться плюсами нужны прямые руки и немного знаний с капелькой мозгов. Не имея этого, скорее навредите своей сети.
Стабильная работа недорогих железок на больших объёмах? Скорее нет, чем да. Из 60 закупленных 4 сдохли в течение года.
То есть итого:
Для малого бизнеса? Конечно!
Для извращений? Несомненно!
Чтобы заткнуть внезапную дырку, где нужен NAT и ACL? Да! Возьми с полки
Для тестов и дебага сетевых проблем? Да, во многих случаях подойдёт.
Для обучения? Скорее да, чем нет. Но лучше не первым устройством.
Для массового домашнего использования? Нет.
Для эникейщика без знаний? Нет.
Для эникейщика со знаниями? Да.
Для массового кровавого энтерпрайза? Нет.
Для удовольствия? Кому как.
Ну и как обычно, это инструмент и он хорош для своих, подходящих ему задач.
👍8🤔2
Давно было
Сейчас на меня иногда нападает старческий бубнёж и желание всё проконтролировать: а ты это сделал, а ты это учёл, а ты на это обратил внимание? Ребята же, с которыми я работала в начале карьеры, обладали здоровым похуизмом и некоторой наивной верой, что у окружающих их айтишников всё в порядке с логикой. Иногда это выливалось в инциденты.
Был случай, когда у нас сдохла прокся в выходные. Интересно, кто-то помнит ещё Forefront TMG? Жил он у нас единственный на десктопном, а не стоечном железе и чутко реагировал на изменение микроклимата в серверной, как я в последствии узнала. Также он любил уйти в ребут и не включиться, лишив всех радости попадания в интернет. Почему все всполошились в субботу уже не помню, та организация не работала круглосуточно. Может быть был отчет у бухгалтерии и они не могли выжить без контакта с налоговой, может ещё что. Я тогда, как не занятый ничем человек, припёрлась в офис, ткнула в серверной кнопку включения, убедилась, что интеренет есть и уехала. Ну да, тепловато было в серверной, но я с улицы даже куртку не снимала, ну тепло и тепло, мало ли, отопление включили. Отписалась, что включила и на этом всё.
В 9 утра понедельника прокся сдохла вновь и кто-то пошел на неё смотреть. Вернулся и спросил: "Наташ, а ты когда в субботу приезжала, кондей работал?". Я говорю: "Не помню, даже не посмотрела. Показалось, что тепло как-то, но решила про это не писать".
Пойдём, говорит, со мной, посмотришь.
Скажем так, металлическая дверь в серверную, конечно, не обжигала, но была неприятно горячая. Воздух был градусов 50, наверное.
На меня грустно посмотрели, мысленно, видимо, попытались избавиться от матюков, и сказали: "Почувствовала, что что-то не так, лучше напиши. А о том, что в серверной тепло сообщай всегда! Сразу! В серверной не должно быть тепло!".
С тех пор мы обзавелись термометром, который шлёт смс-ки, заббиксом, вторым кондеем, что, впрочем, всё равно не спасло нас от пары жарких деньков в серверной в своё время. Были в нашей жизни и вентиляторы, и серваки в кабинете, чтоб серверная не запеклась совсем, даже предложения сгонять за жидким азотом и лить на пол)
Я теперь этот (и не только) инцидент и свою тупизну иногда вспоминаю и на меня нападает это вот старческое бу-бу-бу, хотя я с ним борюсь. Проверь, отпиши, точно всё в порядке? А это в порядке? А то?
Иногда, не смотря на все меры контроля, проходя мимо серверной, трогаю дверь рукой - не горячая ли?
На картинке смс от температурного датчика более поздних времён. С температурой (47 - это она).
Сейчас на меня иногда нападает старческий бубнёж и желание всё проконтролировать: а ты это сделал, а ты это учёл, а ты на это обратил внимание? Ребята же, с которыми я работала в начале карьеры, обладали здоровым похуизмом и некоторой наивной верой, что у окружающих их айтишников всё в порядке с логикой. Иногда это выливалось в инциденты.
Был случай, когда у нас сдохла прокся в выходные. Интересно, кто-то помнит ещё Forefront TMG? Жил он у нас единственный на десктопном, а не стоечном железе и чутко реагировал на изменение микроклимата в серверной, как я в последствии узнала. Также он любил уйти в ребут и не включиться, лишив всех радости попадания в интернет. Почему все всполошились в субботу уже не помню, та организация не работала круглосуточно. Может быть был отчет у бухгалтерии и они не могли выжить без контакта с налоговой, может ещё что. Я тогда, как не занятый ничем человек, припёрлась в офис, ткнула в серверной кнопку включения, убедилась, что интеренет есть и уехала. Ну да, тепловато было в серверной, но я с улицы даже куртку не снимала, ну тепло и тепло, мало ли, отопление включили. Отписалась, что включила и на этом всё.
В 9 утра понедельника прокся сдохла вновь и кто-то пошел на неё смотреть. Вернулся и спросил: "Наташ, а ты когда в субботу приезжала, кондей работал?". Я говорю: "Не помню, даже не посмотрела. Показалось, что тепло как-то, но решила про это не писать".
Пойдём, говорит, со мной, посмотришь.
Скажем так, металлическая дверь в серверную, конечно, не обжигала, но была неприятно горячая. Воздух был градусов 50, наверное.
На меня грустно посмотрели, мысленно, видимо, попытались избавиться от матюков, и сказали: "Почувствовала, что что-то не так, лучше напиши. А о том, что в серверной тепло сообщай всегда! Сразу! В серверной не должно быть тепло!".
С тех пор мы обзавелись термометром, который шлёт смс-ки, заббиксом, вторым кондеем, что, впрочем, всё равно не спасло нас от пары жарких деньков в серверной в своё время. Были в нашей жизни и вентиляторы, и серваки в кабинете, чтоб серверная не запеклась совсем, даже предложения сгонять за жидким азотом и лить на пол)
Я теперь этот (и не только) инцидент и свою тупизну иногда вспоминаю и на меня нападает это вот старческое бу-бу-бу, хотя я с ним борюсь. Проверь, отпиши, точно всё в порядке? А это в порядке? А то?
Иногда, не смотря на все меры контроля, проходя мимо серверной, трогаю дверь рукой - не горячая ли?
На картинке смс от температурного датчика более поздних времён. С температурой (47 - это она).
🔥6👍1
Первая командировка
В первую командировку я уехала спустя месяцев 10 работы. Задача была "присоединить филиал". То есть, нам досталась уже какая-то структура от другой организации и мы её приводим к своим стандартам, ставим свой софт, подключаем к сети и домену, заводим всем учетки и т.д. Ехала я и спец по бухгалтерским прогам, тогда у нас был "Турбо Бухгалтер".
Родители, помятуя проводы в лагерь и общий мой топографический кретинизм, решили проводить меня на вокзал, как я ни отбивалась словами "я уже не маленькая". Не знаю, насколько им полегчало, когда они меня сдали коллеге в виде лысого мужика лет 50, но, по крайней мере, они были уверены, что я не потерялась по пути.
Первое, что я сказала, отделавшись от родителей, было "давай на ты". Второе: "ты пьёшь?".
"Ну не прямо сейчас же" - разумно ответил коллега и мы поехали.
Нам обещали сервер. Сервер привезти не успели или не захотели. Грустно уточнили, может мы как-нибудь перетопчемся? Мы отказались перетоптаться (договаривались! За две недели!) и нам таки повезли его из соседнего города, всего-то 140км. Ну вернее как, я хлопала глазами, а коллега читал нотацию директору о договорённостях. Я всё же тогда не обладала настойчивостью и наглостью, но кивала и мотала на ус. Пока мы ждали сервак наступила ночь, кто-то сбегал за пивом, за окном было -36 мороза, а в кабинете +30 тепла. Мы вяло ковыряли то, что есть, и травили байки в домашней атмосфере, было здорово)) Сервер таки довезли, я накатила систему и мы пошли по домам.
На второй день я взяла с собой тапочки, ибо внутри офиса было жарево, а про сменку я не подумала.
В филиале я в первый раз увидела, что витуху можно разделить по парам на разные устройства, а также разводку в виде проводов намотанных на батарею (чтоб по полу не валялись).
Кажется, единственное, что я сделала нормально с первого раза - это подняла контроллер домена. То ли минимальный опыт сказался, то ли там негде косячить было. Настроила сетевой экран и подняла канал не сразу, но победила в результате. Сервер касперского я тоже развернула, потом его раза три перенастраивала с нуля уже удалённо, потому что накосячила везде, где возможно. На самом деле уже не помню, что там ещё настраивалось (возможно, dhcp, шары, виртуалку с нашим софтом, принтерам помню сеть меняли, всё в домен вгоняли), но помню ощущение, что я ещё месяца полтора разгребала результаты своих косяков 😅 Ну, я внедрила, я и разгребла. Зато нормально погрузилась в инфраструктуру филиала.
С коллегой мы культурно выпивали после работы и внезапно сошлись на почве любви к фантастике, в последствии продолжили иногда совместно выбираться в бары по возвращении в Москву. Позже я с ним ещё не раз ездила в командировки и никогда это не были полностью трезвые поездки, мой вопрос в начале был излишним)
Итог: ехала я в командировку не совсем понимая, что меня ждёт. Вообще был новый опыт и хорошо, что с коллегой вместе, который взял на себя переговоры с директором и вот это всё. Косяки были не критичные и разгреблись в процессе работы, зато я почувствовала в себе силы сделать, спланировать, внедрить что-то.
На картинке "разводка" витухи оттуда
В первую командировку я уехала спустя месяцев 10 работы. Задача была "присоединить филиал". То есть, нам досталась уже какая-то структура от другой организации и мы её приводим к своим стандартам, ставим свой софт, подключаем к сети и домену, заводим всем учетки и т.д. Ехала я и спец по бухгалтерским прогам, тогда у нас был "Турбо Бухгалтер".
Родители, помятуя проводы в лагерь и общий мой топографический кретинизм, решили проводить меня на вокзал, как я ни отбивалась словами "я уже не маленькая". Не знаю, насколько им полегчало, когда они меня сдали коллеге в виде лысого мужика лет 50, но, по крайней мере, они были уверены, что я не потерялась по пути.
Первое, что я сказала, отделавшись от родителей, было "давай на ты". Второе: "ты пьёшь?".
"Ну не прямо сейчас же" - разумно ответил коллега и мы поехали.
Нам обещали сервер. Сервер привезти не успели или не захотели. Грустно уточнили, может мы как-нибудь перетопчемся? Мы отказались перетоптаться (договаривались! За две недели!) и нам таки повезли его из соседнего города, всего-то 140км. Ну вернее как, я хлопала глазами, а коллега читал нотацию директору о договорённостях. Я всё же тогда не обладала настойчивостью и наглостью, но кивала и мотала на ус. Пока мы ждали сервак наступила ночь, кто-то сбегал за пивом, за окном было -36 мороза, а в кабинете +30 тепла. Мы вяло ковыряли то, что есть, и травили байки в домашней атмосфере, было здорово)) Сервер таки довезли, я накатила систему и мы пошли по домам.
На второй день я взяла с собой тапочки, ибо внутри офиса было жарево, а про сменку я не подумала.
В филиале я в первый раз увидела, что витуху можно разделить по парам на разные устройства, а также разводку в виде проводов намотанных на батарею (чтоб по полу не валялись).
Кажется, единственное, что я сделала нормально с первого раза - это подняла контроллер домена. То ли минимальный опыт сказался, то ли там негде косячить было. Настроила сетевой экран и подняла канал не сразу, но победила в результате. Сервер касперского я тоже развернула, потом его раза три перенастраивала с нуля уже удалённо, потому что накосячила везде, где возможно. На самом деле уже не помню, что там ещё настраивалось (возможно, dhcp, шары, виртуалку с нашим софтом, принтерам помню сеть меняли, всё в домен вгоняли), но помню ощущение, что я ещё месяца полтора разгребала результаты своих косяков 😅 Ну, я внедрила, я и разгребла. Зато нормально погрузилась в инфраструктуру филиала.
С коллегой мы культурно выпивали после работы и внезапно сошлись на почве любви к фантастике, в последствии продолжили иногда совместно выбираться в бары по возвращении в Москву. Позже я с ним ещё не раз ездила в командировки и никогда это не были полностью трезвые поездки, мой вопрос в начале был излишним)
Итог: ехала я в командировку не совсем понимая, что меня ждёт. Вообще был новый опыт и хорошо, что с коллегой вместе, который взял на себя переговоры с директором и вот это всё. Косяки были не критичные и разгреблись в процессе работы, зато я почувствовала в себе силы сделать, спланировать, внедрить что-то.
На картинке "разводка" витухи оттуда
👍5
Как мы планировали работы по внедрению
Я уже писала на пикабу большой пост про то как мы апгрейдили сеть. Сейчас же опишу подробнее кусочек оттуда.
Задача была внедрить новое сетевое оборудование, плюсом перейти на новую телефонию, новую ip-адресацию, новый vpn, ну и всякого по мелочи. Всё это в примерно 60 филиалах + ЦОД. Пилотные 8 точек были готовы, у нас было чуть меньше 6 месяцев и 52 точки внедрения, задача была не сдохнуть в процессе. Нужен был примерный план операции.
Мы уже ощутили что такое работать три недели с одним выходным, поэтому, чтоб не двинуть кони, нужно было определиться с интервалом. Я прикинула, что каждые третьи выходные в принципе ок, но нужно стремиться к каждым четвёртым (то есть пара выходных раз в месяц условно). Дальше из календаря были выкинуты выходные, входящие в отпуск мой или коллеги. Оставшиеся были разбиты на интервалы по 3-4 недели так, чтобы закончить хотя бы за 3 недели до Нового года.
Получилось 6 дат внедрения. Дальше нужно было разбить 52 филиала на 6. Нам показалось много, мы немного посовещались с руководством и выкинули из списка 2 маленьких филиала, которые можно внедрить в будни (директора согласовали простой). И два маленьких филиала с сильным сдвигом времени от мск, где директор и айтишник согласовали работу "после обеда и до вечера" по местному времени. Оставшиеся надо было разбить на примерно равные по усилиям внедрения.
Что учитывалось:
- размер филиала в рабочих местах
- лояльность и адекватность местного айтишника
- дополнительные сложности (много доп офисов, офис разбит на 4 этажа или вообще на два здания, проблемный* айтишник, плановый ремонт офиса, другие особенности)
- сдивиг часовых поясов (в одну дату нужны и дальние и ближние филиалы, чтоб распределить нагрузку по дню)
Ну вот так, прикинув по жопным ощущениям сложность и раскидав филиалы в табличку по 7-10 штук, всем разослали план и пошли корректировки: отпуск айтишника филиала, сдача отчетности в надзорные органы и т.д. Не хотите в эту дату? Ок, меняем с другим филиалом, но он тоже должен согласиться.
Из интересных наблюдений:
1) Мало кто понимает, что вы в головном офисе одни, а их (филиалов) много, а также что вы не бессмертный пони. Например, стандартная ситуация: звонок из филиала за 5 дней до часа Х с просьбой "а давайте не в эти, а в следующие выходные". Вроде человек видит график, но ему нужно всё равно пояснять, что мы не можем работать три недели без выходных вообще, а также, что оплачивать нам работу на выход в два дополнительных выходных ради одного филиала, который хочет оттянуть, не очень рентабельно.
2) в конце сами собой собираются все проблемные филиалы. Последнее внедрение было тяжелым, потому что, как при сортировке пузырьком, в конец выплыли все самые трешовые. Они постоянно оттягивали, с кем-то менялись и собрались последней кучкой.
После утверждения плана конвейер: накатили железки, выслали, разослали инструкции, сделали подготовку, провели внедрение. Да, у нас был шаблонный конфиг, но нюансы были у каждого свои. Мы не осилили накатить всё оборудование разом и разослать, хотя и хотели. Собственно, разрезанная в процессе внедрения на две части сеть, генерирует нормальное такое количество текучки, которую тоже никто не отменял, поэтому действовали такими волнами.
*Что такое проблемный айтишник? Это тот, который может сгенерировать (плохо)прогнозируемые проблемы:
1) это "мамой клянусь". То есть, вместо собеседования, кто-то из не-ИТ руководства сказал "мамой клянусь, хороший айтишник, сын маминой подруги". Крайне редко из этого получается что-то хорошее. В части внедрения - это рандомное невыполнение инструкций и неправильная оценка затрат времени (как нами, так и им) на ту или иную операцию
2) запойный
3) устраивающий "итальянскую забастовку"
это был пост без морали) просто маааленький кусочек из планирования - как оно происходило на самом деле
Картинка прекрасного автора KotiaForge иллюстрирует моё состояние в начале всего этого))
Я уже писала на пикабу большой пост про то как мы апгрейдили сеть. Сейчас же опишу подробнее кусочек оттуда.
Задача была внедрить новое сетевое оборудование, плюсом перейти на новую телефонию, новую ip-адресацию, новый vpn, ну и всякого по мелочи. Всё это в примерно 60 филиалах + ЦОД. Пилотные 8 точек были готовы, у нас было чуть меньше 6 месяцев и 52 точки внедрения, задача была не сдохнуть в процессе. Нужен был примерный план операции.
Мы уже ощутили что такое работать три недели с одним выходным, поэтому, чтоб не двинуть кони, нужно было определиться с интервалом. Я прикинула, что каждые третьи выходные в принципе ок, но нужно стремиться к каждым четвёртым (то есть пара выходных раз в месяц условно). Дальше из календаря были выкинуты выходные, входящие в отпуск мой или коллеги. Оставшиеся были разбиты на интервалы по 3-4 недели так, чтобы закончить хотя бы за 3 недели до Нового года.
Получилось 6 дат внедрения. Дальше нужно было разбить 52 филиала на 6. Нам показалось много, мы немного посовещались с руководством и выкинули из списка 2 маленьких филиала, которые можно внедрить в будни (директора согласовали простой). И два маленьких филиала с сильным сдвигом времени от мск, где директор и айтишник согласовали работу "после обеда и до вечера" по местному времени. Оставшиеся надо было разбить на примерно равные по усилиям внедрения.
Что учитывалось:
- размер филиала в рабочих местах
- лояльность и адекватность местного айтишника
- дополнительные сложности (много доп офисов, офис разбит на 4 этажа или вообще на два здания, проблемный* айтишник, плановый ремонт офиса, другие особенности)
- сдивиг часовых поясов (в одну дату нужны и дальние и ближние филиалы, чтоб распределить нагрузку по дню)
Ну вот так, прикинув по жопным ощущениям сложность и раскидав филиалы в табличку по 7-10 штук, всем разослали план и пошли корректировки: отпуск айтишника филиала, сдача отчетности в надзорные органы и т.д. Не хотите в эту дату? Ок, меняем с другим филиалом, но он тоже должен согласиться.
Из интересных наблюдений:
1) Мало кто понимает, что вы в головном офисе одни, а их (филиалов) много, а также что вы не бессмертный пони. Например, стандартная ситуация: звонок из филиала за 5 дней до часа Х с просьбой "а давайте не в эти, а в следующие выходные". Вроде человек видит график, но ему нужно всё равно пояснять, что мы не можем работать три недели без выходных вообще, а также, что оплачивать нам работу на выход в два дополнительных выходных ради одного филиала, который хочет оттянуть, не очень рентабельно.
2) в конце сами собой собираются все проблемные филиалы. Последнее внедрение было тяжелым, потому что, как при сортировке пузырьком, в конец выплыли все самые трешовые. Они постоянно оттягивали, с кем-то менялись и собрались последней кучкой.
После утверждения плана конвейер: накатили железки, выслали, разослали инструкции, сделали подготовку, провели внедрение. Да, у нас был шаблонный конфиг, но нюансы были у каждого свои. Мы не осилили накатить всё оборудование разом и разослать, хотя и хотели. Собственно, разрезанная в процессе внедрения на две части сеть, генерирует нормальное такое количество текучки, которую тоже никто не отменял, поэтому действовали такими волнами.
*Что такое проблемный айтишник? Это тот, который может сгенерировать (плохо)прогнозируемые проблемы:
1) это "мамой клянусь". То есть, вместо собеседования, кто-то из не-ИТ руководства сказал "мамой клянусь, хороший айтишник, сын маминой подруги". Крайне редко из этого получается что-то хорошее. В части внедрения - это рандомное невыполнение инструкций и неправильная оценка затрат времени (как нами, так и им) на ту или иную операцию
2) запойный
3) устраивающий "итальянскую забастовку"
это был пост без морали) просто маааленький кусочек из планирования - как оно происходило на самом деле
Картинка прекрасного автора KotiaForge иллюстрирует моё состояние в начале всего этого))
👍5❤1
zabbix и BGP
Я не забыла про канал, просто ваяла большой пост с картинками для пикабу.
Пятница у меня прошла под знаком "ничего не сломай" и я погрузилась немного в zabbix-шаблоны, ибо давно хотелось мониторить как-то состояние BGP на пограничных роутерах. Я в создании шаблонов понимала примерно никак и пришлось много действовать методом научного тыка, сопоставлениея и чуток почитать документации.
Телега не подходит для таких постов с картинками и описанием, поэтому вот ссылка, приятного чтения 😄
Я не забыла про канал, просто ваяла большой пост с картинками для пикабу.
Пятница у меня прошла под знаком "ничего не сломай" и я погрузилась немного в zabbix-шаблоны, ибо давно хотелось мониторить как-то состояние BGP на пограничных роутерах. Я в создании шаблонов понимала примерно никак и пришлось много действовать методом научного тыка, сопоставлениея и чуток почитать документации.
Телега не подходит для таких постов с картинками и описанием, поэтому вот ссылка, приятного чтения 😄
Пикабу
Как я ваяла bgp шаблон для huawei в zabbix
Автор: virrasha
🔥8
"ты делаешь неправильно"
Как только вы начнёте делиться с кем-то тем, что вы делаете на работе, найдутся те, кто вам расскажет, что вы делаете неправильно. Рассмотрим как это может заучать и как на это реагировать:
1) "Все нормальные люди делают вот так, а не так как ты".
2) "А вот мой способ лучше, потому что"
3) "Надо было изначально делать не так, ошибка в самом начале"
4) "Я бы с такими подходами в организации и не начинал работать, увольняйтесь"
Раньше меня это очень напрягало. Ну как же, я делаю всё не так, не успеваю за прогрессом и вообще какой из меня админ, если я сделала не так как мне тут советуют.
Все, абсолютно все советы посторонних людей не учитывают ваши конкретные нюансы. Это могут быть внутренние регламенты компании, безопасников, регуляция Федеральным законодательством. Это может быть наследие компании, которая создавалась 30 лет назад, наличие или отсутствие бюджета, обязанность делать закупки через тендер, наличие или отсутствие техники и кадров с компетенциями. Может быть географическое и политическое расположение, работа в экстремальных условиях или просто прибабах работадателя. Всё, что угодно. И это всё знаете только вы, а никак не ваш советчик, помните об этом. Вы решаете задачу с вашими конкретными ограничениями и наличными ресурсами. Если задача решена - победа. Бизнесу чаще всего насрать, что это немодно, неоптимально и через жопу.
Другой аспект: все категоричные утверждения из разряда "все, всегда, никогда" имеют сноски и исключения. Знаете же, на первой лекции по программированию говорят "никогда не используй goto". А на втором курсе мы копались в ядре линуха (в реализации функций вроде) и там был goto. Почему? А там, нам сказали, люди понимают, что они делают, поэтому им можно.
Утверждение "всегда дели сеть на VLAN'ы" в общем случае верное. Но надо ли к нему прислушиваться админу организации на 10 компов и 1 сервер? Ага, уже уточняем: "всегда дели на VLAN'ы большую сеть". Насколько большую? Ну, пусть больше /24. Ок, купил админ L2 свичи, а между вланами роутинг осуществляет древний маршрутизатор со 100мб портами и никакущей производительностью. Это будет хорошо или нет? Ускорит ли сеть? Или цель не скорость, а безопасность? Насколько безопасность должна превалировать над скоростью в вашей организации? То есть, "всегда дели сеть больше /24 на vlan'ы, если у тебя есть L3 свич или нормальный роутер" - так что ли? И снова будут уточнения про телефонию, например, про характер трафика. Концепцию, надеюсь, вы поняли.
Нужно ли всегда игноривать советы? Конечно нет, очень часто советуют толковые вещи. Но надо понимать, как это применить конкретно в вашей ситуации. Опять же, если вы уже сделали что-то, что можно было сделать лучше - не надо думать, что ваша работа бесполезна. Вы решили задачу в поставленные сроки имеющимися ресурсами, это нормально. К ресурсам относятся и ваши компетенции, не надо этого стесняться (если бы работодатель очень хотел иметь сотрудника с намного более высокими компетенциями, он бы его нанял). Появилось понимание как улучшить - улучшайте.
Я бы сказала, мы рассмотрели пункты 1 и 2. Про то, можно ли сразу было делать хорошо 30 лет назад - в следующей серии.
Как только вы начнёте делиться с кем-то тем, что вы делаете на работе, найдутся те, кто вам расскажет, что вы делаете неправильно. Рассмотрим как это может заучать и как на это реагировать:
1) "Все нормальные люди делают вот так, а не так как ты".
2) "А вот мой способ лучше, потому что"
3) "Надо было изначально делать не так, ошибка в самом начале"
4) "Я бы с такими подходами в организации и не начинал работать, увольняйтесь"
Раньше меня это очень напрягало. Ну как же, я делаю всё не так, не успеваю за прогрессом и вообще какой из меня админ, если я сделала не так как мне тут советуют.
Все, абсолютно все советы посторонних людей не учитывают ваши конкретные нюансы. Это могут быть внутренние регламенты компании, безопасников, регуляция Федеральным законодательством. Это может быть наследие компании, которая создавалась 30 лет назад, наличие или отсутствие бюджета, обязанность делать закупки через тендер, наличие или отсутствие техники и кадров с компетенциями. Может быть географическое и политическое расположение, работа в экстремальных условиях или просто прибабах работадателя. Всё, что угодно. И это всё знаете только вы, а никак не ваш советчик, помните об этом. Вы решаете задачу с вашими конкретными ограничениями и наличными ресурсами. Если задача решена - победа. Бизнесу чаще всего насрать, что это немодно, неоптимально и через жопу.
Другой аспект: все категоричные утверждения из разряда "все, всегда, никогда" имеют сноски и исключения. Знаете же, на первой лекции по программированию говорят "никогда не используй goto". А на втором курсе мы копались в ядре линуха (в реализации функций вроде) и там был goto. Почему? А там, нам сказали, люди понимают, что они делают, поэтому им можно.
Утверждение "всегда дели сеть на VLAN'ы" в общем случае верное. Но надо ли к нему прислушиваться админу организации на 10 компов и 1 сервер? Ага, уже уточняем: "всегда дели на VLAN'ы большую сеть". Насколько большую? Ну, пусть больше /24. Ок, купил админ L2 свичи, а между вланами роутинг осуществляет древний маршрутизатор со 100мб портами и никакущей производительностью. Это будет хорошо или нет? Ускорит ли сеть? Или цель не скорость, а безопасность? Насколько безопасность должна превалировать над скоростью в вашей организации? То есть, "всегда дели сеть больше /24 на vlan'ы, если у тебя есть L3 свич или нормальный роутер" - так что ли? И снова будут уточнения про телефонию, например, про характер трафика. Концепцию, надеюсь, вы поняли.
Нужно ли всегда игноривать советы? Конечно нет, очень часто советуют толковые вещи. Но надо понимать, как это применить конкретно в вашей ситуации. Опять же, если вы уже сделали что-то, что можно было сделать лучше - не надо думать, что ваша работа бесполезна. Вы решили задачу в поставленные сроки имеющимися ресурсами, это нормально. К ресурсам относятся и ваши компетенции, не надо этого стесняться (если бы работодатель очень хотел иметь сотрудника с намного более высокими компетенциями, он бы его нанял). Появилось понимание как улучшить - улучшайте.
Я бы сказала, мы рассмотрели пункты 1 и 2. Про то, можно ли сразу было делать хорошо 30 лет назад - в следующей серии.
👍4👏3🔥1
"ошибка в самом начале"
Как продолжение "ты делаешь неправильно"
Сюда же относится "в нормальных компаниях это давно сделано".
Ну например, "в нормальных компаниях давно есть мониторинг", или "в нормальных компаниях давно собираются все логи и анализируется", или "в нормальных компаниях есть эникейщики, которые занимаются юзерами, а админы таким не занимаются". Ну чистая правда же по всем пунктам, да? Не поспоришь. Вопрос, когда компания становится "нормальной"? Вот замутил Вася бизнес со знакомыми по продаже финтифлюшек: 1 магазин и 8 человек общего штата, а за админа у него мальчик на аутсорсе 4 часа в неделю. Думал ли Вася про первую линию поддержки и сбор логов? Ага, 15 раз, ему бы в плюс попытаться выйти. Но вот через 20 лет Василий уважаемый владелец 47 магазинов и кучи мобильных точек продаж в разных регионов РФ. У Василия солидный оборот, есть стойка в ЦОД и ИТ отдел на 30 человек, со своей внутренней разработкой, первая линия поддержки и вот это всё. И вот в каком-то моменте за эти 20 лет были соответсвующие внедрения, кто-то сказал, а что это мы логи не собираем, а что это по ITIL не работаем и т.д.
Компании не рождаются гуглом или макдональдсом, яндексом или росатомом. В момент старта они не думают как сделать по правилам или красиво, они думают о том, как обогнать конкурентов. В процессе дальнейшего роста компании сталкиваются с определенными проблемами и тогда, для их решения, они уже внедряют эти все полагающиеся "нормальным" компаниям вещи.
Компания начинает собирать логи админки не потому что им некуда деть время и мощности, а потому что теперь там не два админа Саша и Маша, а десяток и нужно разбираться, "а кто это нам сделал такую бяку", чтобы выдать соответствующих пиздюлей.
Соответственно, вы можете попасть на такое внедрение в компании или даже сами его инициировать. Значит ли это, что компания плохая, что не этого имеет? Нет, просто она доросла на данном этапе до этого, всё идёт как надо.
Можно ли всё сломать и сделать хорошо? Ну вот допустим у вас есть деньги, люди, компетенции. В более-менее большой компании всё равно нельзя. Максимальный перерыв в работе может быть пара дней по большим праздникам. А вам менять разом все подходы, инфраструктуру, регламенты, люди должны сразу начать по-новому работать и т.д. Слона нужно есть по кусочкам и улучшать поэтапно так, чтобы бизнес не слишком страдал (а вообще-то подразумевается, что бизнесу от улучшений должно хорошеть).
В части инфраструктуры, если у вас вообще денег столько, что некуда деть, можно построить рядом копию инфраструктуры уже по новым принципам и переезжать плавно на неё. Это требует очень больших денег и желания и встречается настолько редко, что вряд ли вы с этим столкнётесь.
О, ещё вспомнила "нормальные компании нанимают интеграторов и им делают под ключ". Это в сторону админов такой выпад. Совершенно внезапно, тендерная документация и толковое подробное ТЗ для внедрения не берутся из воздуха. Писать это будете тоже вы (ну или ваш начальник с вашей помощью). А потом придут интеграторы и в лучшем случае сделают по ТЗ, в котором вы забыли описать очевидные вещи, потому что навык написания ТЗ тоже не берётся из воздуха. А ещё ТЗ вы с начальником ваяли тоже на основе своих компетенций.
Вывод то какой? Компании обычно не рождаются со всеми внедренными фичами и классными регламентами. На каком-то этапе им это ещё не нужно. Нет ничего страшного, если вы будете именно тем человеком, который что-то внедрит. Нет также страшного, если вам досталось адское наследие "так исторически сложилось". Да, нужно менять к лучшему, работая с тем, что вам доступно. Компания с этой бякой наследия работает и приносит прибыль, смиритесь, что не всё должно быть идеальным, чтобы работать.
Понимание всех этих вещей не приходит сразу. Каждому нужно попытаться спланировать своё "всё сломаю и сделаю хорошо". Нужно попытаться применить какое-то изменение, поработать с людьми, немного понять про финансы и всякое такое.
Как продолжение "ты делаешь неправильно"
Сюда же относится "в нормальных компаниях это давно сделано".
Ну например, "в нормальных компаниях давно есть мониторинг", или "в нормальных компаниях давно собираются все логи и анализируется", или "в нормальных компаниях есть эникейщики, которые занимаются юзерами, а админы таким не занимаются". Ну чистая правда же по всем пунктам, да? Не поспоришь. Вопрос, когда компания становится "нормальной"? Вот замутил Вася бизнес со знакомыми по продаже финтифлюшек: 1 магазин и 8 человек общего штата, а за админа у него мальчик на аутсорсе 4 часа в неделю. Думал ли Вася про первую линию поддержки и сбор логов? Ага, 15 раз, ему бы в плюс попытаться выйти. Но вот через 20 лет Василий уважаемый владелец 47 магазинов и кучи мобильных точек продаж в разных регионов РФ. У Василия солидный оборот, есть стойка в ЦОД и ИТ отдел на 30 человек, со своей внутренней разработкой, первая линия поддержки и вот это всё. И вот в каком-то моменте за эти 20 лет были соответсвующие внедрения, кто-то сказал, а что это мы логи не собираем, а что это по ITIL не работаем и т.д.
Компании не рождаются гуглом или макдональдсом, яндексом или росатомом. В момент старта они не думают как сделать по правилам или красиво, они думают о том, как обогнать конкурентов. В процессе дальнейшего роста компании сталкиваются с определенными проблемами и тогда, для их решения, они уже внедряют эти все полагающиеся "нормальным" компаниям вещи.
Компания начинает собирать логи админки не потому что им некуда деть время и мощности, а потому что теперь там не два админа Саша и Маша, а десяток и нужно разбираться, "а кто это нам сделал такую бяку", чтобы выдать соответствующих пиздюлей.
Соответственно, вы можете попасть на такое внедрение в компании или даже сами его инициировать. Значит ли это, что компания плохая, что не этого имеет? Нет, просто она доросла на данном этапе до этого, всё идёт как надо.
Можно ли всё сломать и сделать хорошо? Ну вот допустим у вас есть деньги, люди, компетенции. В более-менее большой компании всё равно нельзя. Максимальный перерыв в работе может быть пара дней по большим праздникам. А вам менять разом все подходы, инфраструктуру, регламенты, люди должны сразу начать по-новому работать и т.д. Слона нужно есть по кусочкам и улучшать поэтапно так, чтобы бизнес не слишком страдал (а вообще-то подразумевается, что бизнесу от улучшений должно хорошеть).
В части инфраструктуры, если у вас вообще денег столько, что некуда деть, можно построить рядом копию инфраструктуры уже по новым принципам и переезжать плавно на неё. Это требует очень больших денег и желания и встречается настолько редко, что вряд ли вы с этим столкнётесь.
О, ещё вспомнила "нормальные компании нанимают интеграторов и им делают под ключ". Это в сторону админов такой выпад. Совершенно внезапно, тендерная документация и толковое подробное ТЗ для внедрения не берутся из воздуха. Писать это будете тоже вы (ну или ваш начальник с вашей помощью). А потом придут интеграторы и в лучшем случае сделают по ТЗ, в котором вы забыли описать очевидные вещи, потому что навык написания ТЗ тоже не берётся из воздуха. А ещё ТЗ вы с начальником ваяли тоже на основе своих компетенций.
Вывод то какой? Компании обычно не рождаются со всеми внедренными фичами и классными регламентами. На каком-то этапе им это ещё не нужно. Нет ничего страшного, если вы будете именно тем человеком, который что-то внедрит. Нет также страшного, если вам досталось адское наследие "так исторически сложилось". Да, нужно менять к лучшему, работая с тем, что вам доступно. Компания с этой бякой наследия работает и приносит прибыль, смиритесь, что не всё должно быть идеальным, чтобы работать.
Понимание всех этих вещей не приходит сразу. Каждому нужно попытаться спланировать своё "всё сломаю и сделаю хорошо". Нужно попытаться применить какое-то изменение, поработать с людьми, немного понять про финансы и всякое такое.
👏7👍2