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

Итак %username%, тебя взяли на работу. Предположим, что ты более - менее разбираешься в вопросе и умеешь чуть больше, чем картридж поменять. С момента, как ты стал сисадмином, ты взял на себя огромный груз ответственности. Ты отвечаешь не только за то, что-бы ничего не наебнулось - ты отвечаешь за лицензирование. Будь уверен, если придет проверка, твой генеральный прикинется ветошью и не отсвечивая покажет пальцем в твою сторону.

О лицензировании.

Твоя задача не только самостоятельно не устанавливать всякую дичь aka RePack Photoshopа, но и не дать пользователям самостоятельно устанавливать и запускать подобную дичь с флешки и иных папок/носителей.

Об ограничении.

Описанный ниже способ сэкономит твои нервы и придаст уверенности в используемом программном обеспечении. Политика ограниченного использования программ подобна настройке FireWall. Она предполагает определение типа запрета:

- всё можно, кроме указанного в списке.

- всё нельзя, кроме указанного в списке.

Мне по душе второй вариант. Я люблю работать с местоположением программ.

Для начала мы определяем границы возможностей пользователя:

Определим пути, куда пользователь прав на запись не имеет:

- C:\Windows

- "C:\Program Files"

- "C:\Program Files (x86)"

Именно в этих расположения находятся приложения, установленные системой и администратором.

В остальные каталоги и локальные диски пользователь может иметь доступ на запись.

Это значит, что он может сохранить там приложение и выполнять его.

Если мы разрешим запуск приложений только из системных каталогов, мы получаем:

- Перестают работать Амиго, Яндекс браузер и прочее ПО из профиля пользователя.

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

- Никаких шифровальщиков

- Никакого Portable софта.

При этом Администратор может всё.

Интересно? Читай дальше.

Создание объекта групповой политики

После создания объекта, редактируем его. Идем по пути:

[Конфигурация пользователя - Политики - Конфигурация Windows - Настройки безопасности - Политики ограниченного использования программ]

Создаем новую политику.

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

в папке Уровни безопасности выбираем уровень по умолчанию "запрещено".

Далее выбираем область применения политики: все пользователи, кроме локальных администраторов. Это позволит нам устанавливать программы. Разрешаем запуск библиотек: это сохранит работоспособность расширений браузера и ActiveX.

Теперь переходим в папку "Дополнительные правила"

Именно тут нам предстоит создать "белый список".

По умолчанию указаны пути системного каталога и каталога приложений.

Здесь мы будем создавать правила. Нас интересуют два типа правил: правило пути и правило хэша.

Правило пути определяет местоположение файла и разрешает запуск приложений из этого расположения.

Правило хэша определяет контрольную сумму конкретного файла и разрешает его запуск из любого расположения.

Например разрешим людям играть в СТАЛКЕР (ты в курсе, что он работает с флешки). Создадим правило для Хэша, так как мы не знаем букву флешки на компьютерах пользователей.

Это просто для примера. Ты понимаешь, да?

Теперь давай разрешим запуск скриптов из папки Netlogon: создадим правило пути.

Хочешь видеть результат?

Смотри скриншот - ты только что сам заблокировал запуск установки Яндекс.Браузера.

Если-бы не политика, он установился-бы  в профиль пользователя и работал-бы от туда. Та же участь постигнет шифровальщики и "письма из налоговой" с расширением exe и js.

Бери в руки инструмент и будь рука твоя тверда на пути к власти над пользователями, но помни о бухгалтерах. Для бухгалтера с банк клиентами и Контур.Экстерном создай отдельную политику.

Учти, что OneDrive тоже будет заблокирован - разреши его запуск по пути.

Иначе на всех всех компьютерах с Windows 10 при каждом входе будет вылезать ошибка. Если ты хочешь заблокировать OneDrive, ищи другой путь. Но помни: может кто-то его использует.

Так ты отберешь тех, кто им пользуется от тех, кому он не нужен.

И не забывай про обновление ADMX шаблонов.

Всем привет!

Обои поклеил и пиво льется рекой, а это значит, что Уханов снова вещает.

А поговорим мы сегодня о пароле локального администратора.

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

Что нужно было сделать, что-бы не выстрелить себе в ногу? Вывести компьютер из домена, используя пароль локальной учетной записи с правами администратора. Таким образом можно быть уверенным, что помнишь пароль.

Установка пароля через групповые политики.

Чаще администраторы прибегают к установке на компьютеры домена одинакового пароля средствами групповых политик.

Почему это плохо?

Пароль администратора хранится в зашифрованном виде в xml файле  каталога групповых политик. Файл доступен для чтения всем авторизованным пользователям домена.

Считаете, если он зашифрован, то вы в безопасности? Как бы не так: Microsoft опубликовала 32-битный AES ключ шифрования пароля.

Майкрософт категорически не рекомендует так менять пароли, а в новых версиях Windows Server настоятельно говорит так не делать. Такие дела, малята: получить пароль админа проще простого.

Бюллетень MS14-025 запрещает установку пароля таким образом. Поле пароля неактивно.

А ещё может случиться необходимость предоставить пользователю административные привилегии. На моей практике такое было пару раз -  я потерял связь с компьютером и ничего не мог сделать: Быстрой помощи в Windows 10 ещё не было, а TeamViewer или AmmyAdmin  блокировались политикой ограниченного использования программ. На часах ночь, а принтер у человека не работал.

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

Local Administrator Password Solution - это официальный инструмент для установки и периодической смены пароля администратора.

Он бесплатен в использовании и прост в настройке.

Что он умеет?

- с заданной периодичностью компьютер сам меняет пароль указанной учетной записи.

- Пароль хранится в AD

- У каждого компьютера свой пароль

- параметры пароля и учетной записи настраиваются

При помощи утилиты LAPS UI можно узнать текущий пароль - надо лишь указать имя компьютера

Скачать чудо утилиту с подробнейшим мануалом можно по ссылке выше.

Хорошая статься на WINITPRO тут.

Коллеги, всем хороших выходных и прекрасного настроения.

Поделюсь фото пенного на фоне рабочей машины с дисками, которые так любит вынимать мой сын. Благо, Storage Spaces спокойно переносит кражу одного и даже двух дисков массива.

А как вы решили проблему паролей?

В крупных компаниях федерального, а то и мирового уровня, как известно, есть своя техподдержка, а то и целый NOC. NOC - это network operation center, иногда ещё называется ЦУС - Центр Управления Сетью. Отделять сетевую часть от всей остальной ИТ-инфраструктуры компании - весьма полезно и эффективно, от того, наверное и дорого.
Но иногда NOC - это один человек, да и тот сисадмин. Системные администраторы, сетевые инженеры и программисты - это абсолютно разные ИТ-специализации, вот сисадмин это часто что-то по серединке с дополнительными навыками вроде "Монтажник СКС" ,  "Эникей" и "Тыжпрограммист, почини мне компьютерный стул" .
Но нагружают его как полноценного сетевого инженера, а может даже ещё и как полноценного программиста одновременно. А платят то как обычному админу. Крепитесь, ребятки, всю работу в своей зоне ответственности делайте строго под отчетность, а не в своей - отфутболивайте. Хотят вам новый функционал - пусть и денежки платить хотят.
Итак, Админы.
Видимо от такого количества ответственности эти товарищи иногда борзеют.
- "Да у меня домашний айпишник не пингуется с канала на работе! Да там по любому у вас какая-то проблема, проверяйте своё барахло!"
Думаю: "Слыш, блядь, барахло. Это барахло - ASR 9000 , у циско конечно много всяких разных сборок и комплектаций каждой железяки, но даже в самой дешёвой эта штука стоит дороже, чем тебя на органы продать."
- "Я вот ваш домашний канал нашёл, и он пингуется с сервака, а с вашей сети на работе - нет. Вот давайте вы напрямую подключитесь дома и посмотрим!"
Звоню через 20 минут. "Ну что?" - "Ой, пингуется! Надо то было всего одно правило прописать!"
Это при том, что втирал мне, что там микротик и никакого фаерволла нет. Наверное он понимает под фаерволлом - программно-аппаратный комплекс, а не встроенную защитную софтину в роутер.
И сидят они, мамкины Cisco Certified, и заливают нам, что циска у них хорошая, что там проблем быть не может, нет-нет, ни в коем случае!
Ага, как же, тут большие дяди из Москвы так с одним девятитонником прикурили, что даже вендор ничего внятного кроме пары костылей не подсказал. А ты, говоришь, циска у тебя! Ну пиздец, панацея!
Другой - сдаёт проблему с телефонией через L3VPN канал.
Я: Дядь, ты как бы в курсе, что ты можешь 60% трафика прокрасить в REA преседенс и у тебя всё будет летать? А сейчас ты ничего не красишь, получается каша-малаша из голосового трафика и данных, в ВЕ-преседенсе, а там кто успел того и тапки. Настрой QoS у себя и будет тебе счастье.
А: QoS? А чойта?
Он бы может и знал, если бы предыдущий админ, тот, кто всё принимал записал в документации к каналу. "На канале QoS, на телефонию прокрасить 60% в REA, остальное красить в BE" . Админ загуглил бы, разобрался и всё сделал как надо. Но нет же, блядь, после нас - хоть потоп.
Далее - Техподдержка.
Чаще всего у клиентов есть своя техподдержка где-нибудь в Москве, или наоборот в регионе, где ЗП специалистом за ту же работу можно платить по-меньше.
Подход, в целом, хороший. Есть дежурный, который всегда может сдать проблему провайдеру , или же оперативно проверить восстановление. Вот только тут есть свои нюансы.
- Та же проблема с документацией. Ну никак не хотят документировать свою же собственную связь. Какой телефон на самой точке? А хз щас поищу. Где конкретно на точке железка твоя? - А хз, фоток нет. После этого через 3 звонка и 15 минут разговора, ты находишь с каким-нибудь менеджером ресторана циску до которой видишь связь, грузишь её, и о чудо! Всё работает!
И циска не провайдерская ниразу, то есть по логике вещей всё это должна была проделать техподдержка при обращении с точки ещё.
- Проблема с работами , которые нужно выполнять физически на объекте. Роутер сдох, на точке специалистов нет, техподдержка в Москве,  город - Усть-Перепиздюйск, а провайдер в железки клиента лазить права не имеет, . В лучшем случае в какой-нибудь аутсорс позвонят, в худшем - этого продавца с точки и направят роутер покупать.
- Проблема с доступом и конфигурированием оборудования. Это чаще когда техподдержка не внешняя, а штатная, первая линия сидит где-то в РФ, а все доступы и настройки у инженеров из-за бугра. И начинается тут: "Ой у нас доступов нет, инженеры в Голландии, вы нам на почту напишите, что и где проверить/прописать надо - мы им перешлём".
И сидят терпят потом неделю, пока эти инженеры им ответят, когда там работы эти провести сможет студент, который пару лаб в packet tracer сделал.
Ну, и наконец NOC - дежурные инженеры в таких центрах зачастую серьёзные ребята, говоришь с ними совершенно свободно, как с коллегами. Всё понимают, да только ленятся. "Я человек простой, у меня мониторинг завизжал - я скриншот в письмо приложил и провайдеру пульнул" .
Естественно, откуда и куда мониторинг этот самый мониторит - мы понятия не имеем, техподдержка им заведёт тикет на примерно-подходящий канал, а нам сиди потом за всех работу делай. Физический адрес сверь, айпишник сверь. А если L2 канал - так вообще пиздец. Какие там таблицы коммутации, вы что, У НАС ПО МОНИТОРИНГУ НЕДОСТУПНО!!!11.
Говаривали мне инженеры, у которых я обучался в своё время, что WYSIWYG для школьников. И правильно говаривали. Когда у тебя более двух точек L2VPN, и весь трафик гоняется в одном вилане - провайдер в случае отвала чего-нибудь по L3 все равно маки видит с двух сторон, тут нужно указывать какие конкретно маки перестали прилетать.
Мораль басни: Если вы поддержка - не ленитесь задокументировать все каналы клиента ( для этого можно например провайдеру информационные ТТ/кейсы завести, чтобы просто прислали что там видно от вас и что там у них стоит) .
Не футбольте сотрудников сразу к провайдеру - зайдите на оборудование и проверьте , что видно от провайдера и от локальной сети.
Предоставляйте как можно больше информации, особенно если услуга работает, но плохо. Откуда мониторите и IP, куда мониторите и IP. В чём проявляется проблема у пользователей, что видно на оборудовании: ошибки на аплинке, нагрузка на процессор, температура, статус/наличие фаерволла и акцес-листов.
Свитч - не хаб, представляете. Каждый раз, когда ты покупаешь каталист и не настраиваешь на нём управление - где-то там плачет один инженер техподдержки.
И нет, это всё проверяется/настраивается недолго, у меня на аналогичную проверку по нашей сети уходит в среднем минут 17. А железок то по каждому каналу по-больше будет.
P.S. Респект таким пацанам, которые могут в звонке зайти на циску, сделать show processes cpu history, show int X/X, и законфигать там load-interval 30 .
Бля, один как-то даже научил тётеньку на объекте на циску через PuTTy ходить с минимальными show-правами. Задиктовал команды, всё проверила. Красота.

В первой части я писал, как нужно организовать сеть в офисе, чтобы всё работало , а когда ломается - быстро чинилось. Но что же будет, если этого не делать? Поведают нам вымышленные действующие лица с реальными прототипами.
Со стороны провайдера:  - Инженер №1.
Со стороны бизнес-центра: (арендодатель)- Инженер №2.
Со стороны клиента:
Маша - офисный планктон №1
Саша - Офисный планктон №2
Петя - Офисный планктон №3
Вася - бывший айтишник клиента.
И вот, авария. Ничего не работает. По предыдущим заявкам - 2 из 3 проблема на оборудовании клиента, 1 - решилось перезагрузкой оборудования провайдера.
Что видно? - А связи нет с клиентским оборудованием. Провайдерское в порядке.
Звонок Провайдер-Клиент. Трубку берёт Маша.
Инженер№1: Здравствуйте Маша, нет связи с вашим роутером D-Link, давайте его найдём и проверим.
Маша: Ну я вот нашла наш роутер. Написано Zyxel Keenetic
Инженер№1: Это не главный роутер, давайте искать дальше, где всё ваше оборудование?
Маша: Ну вот стоит, тут какая-то большая коробка D-Link DES XXX , и другие, не подписанные.
Инженер№1: Это скорее всего не то, но теоретически так тоже можно настроить. (Известно, что эта линейка - коммутаторы, но в роутинг они тоже могут немножко) . Давайте перезагрузим, питание - сзади с краю, слева от вас. (Гугл картинки - отличная штука)
Маша: Он тут впритык к стене стоит и на нём куча других устройств, я не могу его отодвинуть. Саша, Петя, помогите мне!
Саша и Петя: бубубу
Маша: Ну ребята! Работа стоит! Давайте сюда!
Саша в итоге ничего не понял, а Петя понял, но ничего сделать не смог. Всё оборудование в куче, только тронь - всё посыпется.
Инженер№1. Ладно, сейчас я вашему бывшему айтишнику позвоню, может он что-то помнит.
Вася: А я уже не помню что там, то ли роутер то ли свитч, то ли D-Link , то ли что, мне плевать.
Опять звонок Пете.
Инженер№1. Ничего не помнит ваш айтишник. Документацию оставил? Директора хотя бы информировал?
Петя: Нет, и директору по барабану. Я могу всё оборудование выключить через ИБП и включить.
Инженер№1: Ну давай.
Петя: А я ничего не сломаю?
Инженер№1: Сходимость сети должна быть, если оборудование после переключение питания не восстанавливается - это проблема с оборудованием и с ним нужно разбираться. Созвон через 5 минут.
Через 5 минут.
Петя: Я выключил ИБП, всё погасло, включил, но оборудование не запускается, ничего не горит!
Инженер№1: Значит переключай питание на каждой железке по отдельности.
Петя: Я не знаю, я не умею, там много проводов.
Инженер№1: Ну кто ж тебе виноват, что на связь всем насрать у вас в конторе. Дай мне Машу, ну тебя нахуй. 
Инженер№1: Маша, нашли ещё что-нибудь?
Маша: Нет, только это.
Инженер№1: Сейчас я арендодателю позвоню, может они что-то знают.
Возникает вопрос: Зачем всё это? А затем, что провайдер поддержкой клиентского железа не занимается. И против организации таких услуг вроде как ФАС выступает. Скорее всего это как гугл хром по умолчанию на железках на базе Android. Мол, пусть клиенты на открытом рынке выбирают себе стороннюю поддержку, а не вы им навязывать будете. Потому поехать и ткнуть клиента носом - 100$ .
Далее звонок провайдер-арендодатель.
Инженер№1: Дядь, тут такое дело. У клиента беда, а он ничего не понимает, может подскажешь, куда там в офис главный кабель приходит?
Инженер№2: Понятия не имею, мы только доступ дали, всё между вами и их айтишником делалось.
Инженер№1: Нет у них айтишника больше.
Инженер№2: Ну , нет айтишника - пусть страдают. Мы помогать не обязаны и не будем. Поднимайте документацию, ориентируйте сами. Будете отправлять людей - пишите, доступ дадим.
Документацию подняли, оборудование провайдера с Машей перезагрузили - разумеется, безрезультатно, ибо видно, что оно и так в работе. Кабели идут куда-то под потолок, скорее всего там главная железяка клиента, а Маша - метр с кепкой, туда не достанет.
Условия выезда для демонстрации сервиса с компа Маше озвучили, она с директором перетёрла, и решили своими силами пока проверить. Это в пятницу то! Скорее всего забьют на все выходные.
Но свой айтишник - это дорого ведь!
Да не нужен свой айтишник, вызови аутсорс. Просто забей в гугле "Настройка роутера %городнейм% ", "ИТ поддержка %городнейм% " . Ребята из Москвы, кто занимается, расскажите в комментариях, сколько стоит расставить нормально железячки клиента, пометить провайдерский кабель на случай поломки?
В данном конкретном случае, если бы Маша нашла кабель провайдера и перезагрузка её роутера не помогла - провайдер бы с ней подключился одним компьютером, а там в интернете и инструкцию по настройке роутера можно найти, и аутсорс нагуглить, если манипуляции с ним не увенчаются успехом. А если компьютером подключились и не работает - так это сходу бесплатный выезд!
Заценили, какая простыня вышла?
А теперь посмотрите на другого клиента - контакт со стороны -  Лиза.
Лиза ещё во время заведения заявки подключилась компьютером напрямую - не работает.
Инженер№1: Здравствуйте Лиза, сейчас за компьютером?
Лиза: Да.
Инженер№1: Выньте сетевой кабель.
Лиза: Хорошо. Вынула.
Линк на оборудовании погас, Лиза всё правильно сделала. Проверка показала, что связь с компом Лизы внутри сети есть, а из внешки - нет.
Инженер№1: Лиза, подключите обратно кабель. Нажмите Win+R, далее впишите cmd. Здесь - ping 8.8.8.8 нажмите enter, говорите что пишет.
Лиза: Привышен интервал ожидания запроса.
Инженер№1: Хорошо, сейчас всё проверим.
Запрос отправили на проверку маршрутизации, там обнаружился лежачий узел в ядре сети, съездят да починят, у клиента никаких головняков.
Тут простыня сильно меньше, правда?
Мораль басни: Разбирайтесь в своей сети, заведите свой аутсорс. 
Мораль басни для айтишников: Не технический персонал - не полные балбесы, если вы оставите достаточно информации, то провайдер сможет их руками всё починить, если проблема с вашей стороны. Верьте в своих коллег, они может не очень умные, но зато очень исполнительные.

Обсуждали мы с @pfsenses нехорошее поведение человека из вот этого поста и вспомнилось мне, что давно хотела написать пост об этике в работе системного администратора. В том числе – поднять вопросы, на которые у меня нет четкого ответа. Обсуждение приветствуется.

Итак, проблема номер 1 – доступность данных, систем и манипуляций с ними. Будем честны, если вы админ небольшой фирмы или глава админов (в смысле, не менеджер, а всё ещё админ) фирмы среднего размера, то вы можете сделать с системой всё. Исключение составляют большие фирмы с реальным разделением труда или задроченные на ИБ (большие банки, например, или там ФСБ), где половинкой пароля владеет админ, а половинкой безопасник, или сети между собой не связаны или еще какие крутые заморочки. Мы про реальную жизнь, а она подсказывает, что админ средней компании может сделать всё. Конечно, грохнуть всю систему – это уголовно наказуемо. И если не совсем идиоты её проектировали, то и восстановлению она более-менее поддаётся. Но серьёзно поднасрать и устроить длительный перерыв работы компании – вообще не требует усилий. Я считаю, что мы этого не делаем потому что

а) ещё раз – это уголовно наказуемо,

б) Это «волчий билет» в профессии

в) А нафига? Профита нет, я это любовно строил, а теперь ломать?

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

Вопрос номер 2 – доступность информации работодателя и личной информации сотрудников. С базами работодателя понятно, все мы (надеюсь) подписывали бумажку о неразглашении и нераспространении. Слить базу - опять же, уголовно наказуемо, «волчий билет» и всё такое. Однако, идиоты, сливающие базы, находятся и их успешно ловят. ИМХО – оно того не стоит.

По второй части - кому из нас не приносили личный/корпоративный ноут на «починить», диск на «восстановить», мобильник на «настроить». У кого пользователи совсем не хранят на рабочих ПК фоточки с отпуска и т.д.? Волей-неволей мы знаем кучу маленьких грязных секретиков других сотрудников. Я считаю неэтичным распространение личной информации людей без их разрешения. Но люди! Вы думайте головой, когда относите свою технику или даёте свои личные данные кому-то! О, ещё классная штука – оставить свой телефон, пароли, кредитку и сказать «ну ты там мне настрой appstore». В общем, что у людей в голове – мне не ясно, но пользоваться доверием этих наивных человеков мне не позволяет совесть. Еще и рассказать им пытаюсь о том, что они не правы, так разбрасываясь данными.

Вопрос номер 3, самый для меня неоднозначный, слежка за сотрудниками. У нас всё цивильно, в договоре это прописано, у старых сотрудников - отдельным приказом с ознакомлением. Однако, слежка за тем, с кем приятельские отношения, слежка за админами филиалов – доставляет некоторый моральный дискомфорт. Особенно, когда они попадаются на горячем. В целом, хорошо, что я плохо схожусь с людьми. Для себя я определила, что есть мой отдел (за которым мне не поручат следить) и есть остальные. Всех предупреждали. Ясно, что инфа, скажем, по посещенным сайтам, предоставляется только по заказу руководства. Но вот слив информации (как в истории с Почтой России, например) – повод для сообщения безопасникам. А как эту дилемму решаете вы?

Вопрос номер 4 частично связан с предыдущим. Это разделение личного и рабочего. С этим мне помог научный руководитель в своё время. Какими бы вы приятелями не были, сколько бы пива не выпили, но личные отношения остаются личными. А по работе у вас есть рабочие обязанности, приказы должны исполняться, отчеты делаться и права урезаться. Да, в среде ИТ обычно неформальные отношения, но это не должно мешать работе или создавать дыры в безопасности.

Вопрос номер 5 – взаимоисключающие требования руководства. Хорошо, если это решается письмом непосредственному руководителю. Но вот, например, дилемма: равные по иерархии начальники просят доступ к шаре служб друг друга (например, финансисты и кадровая служба). И оба же категорически запрещают доступ других служб к своей шаре. Оба они мне не начальники, мои предложения по созданию им папки обмена слушают не всегда. Мой руководитель также не может выдать решение, так как решить в любую сторону – нарушить указания обоих. Обычно таки решается созданием папки обмена (иным компромиссным решением при схожих ситуациях). Как вы разрешаете такие вопросы?

Вопросы номер 6 и 7 на самом деле связаны – это обучение сотрудников и документирование. Под обучением я имею в виду именно передачу знаний среди своих же сотрудников от старших/знающих к младшим/не знающим. Собственно, два аспекта: вы не обучаете и думаете, что незаменимы; или вы обучаете, получаете квалифицированных сотрудников и учитесь сами чему-то новому. Короче, я за обучение. Под документированием я имею в виду составление схем сетей, сводок информации, документирование всех нетипичных действий с системами. То есть, если я уеду в отпуск в горы без связи, кто-то из коллег, пользуясь документацией, сможет сделать то, что делала обычно только я. И да, меня можно уволить, а документация останется. Я считаю это правильным. А вы?

Вопрос номер 8 – отношение к пользователям. Ладно, это не про сисадмина, а про эникейщика. Но он может работать у вас в отделе, или вы можете его иногда подменять на время отпуска. Честно, я ругаю за стёб над пользователями и издевательские шутки. У себя внутри отдела можно обсудить их умственные способности в каких угодно выражениях, но с пользователями будь вежлив и считай, что у них нет чувства юмора.

Вопрос 9 - взаимоотношение с внешними системами. Сюда включу 2 аспекта. Первый – настройка систем, влияющих на внешнюю сеть. Это ваша внешняя зона DNS, настройка внешних IP-адресов, почтовик, возможно, у кого-то BGP. Я не беру телеком, я про обычные конторы. Принцип: не знаешь – не настраивай наобум. От этого зависит работа не только вашей конторы, но и корректная работа Интернет в целом. Второй аспект – взаимодействие с сообществом. Принцип: знаешь, как решить – поделись решением.

Пишите, кто как относится к перечисленным вопросам. У кого какие ещё этические проблемы или моральные дилеммы возникают в связи с профессиональной деятельностью?

Работаю сетевым инженером в сегменте B2b. Примерно в половине случаев - причины аварий на стороне клиента, а то и вовсе нет никакой аварии, есть не очень хороший менеджмент. Попробую рассказать, как же организовать связь для своего бизнеса, ибо уж очень часто орут "ДА МЫ ТУТ ЗНАЕТЕ СКОЛЬКО ДЕНЕГ ТЕРЯЕМ?! МЫ ВООБЩЕ ЗА ЧТО ПЛАТИМ ЦЕЛЫХ 3 ТЫСЯЧИ??!!?"
Будет очень много букв, но если у вас свой бизнес, если вы ответственны хоть каким-то боком за связь в бизнесе, если вы от неё сильно зависите - вам нужно это прочитать. Сами ничего не решаете - покажите тем, кто решает, это же ВАШИ деньги.
1. 3 тысячи вы платите не за эти несчастные 5 мбит, а за гарантию того, что за определённое время, например сутки вам восстановят полностью нерабочий канал. Я могу позвонить на личную мобилу не в рабочее время начальнику подрядной организации , если его подчиненный факапит сроки или не выходит на связь. А для восстановления домашнего интернета вам так сделают? Нет.
2. Если вы имеете риски потерять какой-то тендер на сотни тысяч - имейте резервный канал. А лучше два. Один через кабель, второй через радио-канал точка-точка с совершенно другого здания и один по 3G/4G. Всякие там биржи и производства имеют по 5 и более каналов связи самых разных.
3. Чтобы не тыкать провода туда-сюда ручками - найдите нормального айтишника. Не просто какого-нибудь мамкиного сисадмина, а человека который либо профильное образование закончил по телекому, либо сертификацию у лидеров рынка проходил ( Cisco Certified, MikroTik , Juniper , и т.д. ) . Периодически можно встретить сертификацию от телекоммуникационных компаний, которые за бесплатно преподают в университетах - такие сертификаты ценность имеют только для приема на работу в сами эти компании, но объём знаний дают тот же самый. Ну и идеальный вариант - это инженер, который работал в телекоммуникационных компаниях и знает, как должна управляться сеть. Если деньги есть - то к вашему вниманию тьма аутсорсинговых компаний, которые занимаются исключительно поддержкой локальной ИТ-инфраструктуры для юр. лиц.
4. Если вопрос потери прибыли не стоит в таких масштабах , а нужно чтобы просто работали терминалы на торговых точках, то к выбору оборудования и управлению оным нужно так же подходить весьма ответственно. Здесь я распишу в подробностях и с красочными примерами.
- ДА У НАС СЕРЬЁЗНЫЙ, ПРОФЕССИОНАЛЬНЫЙ РОУТЕР, ОН НЕ МОЖЕТ ЗАВИСНУТЬ. Ага, ASUS, как же. Надёжность роутера не измеряется количеством антенн которые туда понатыкали китайцы. Именно с этими асусами постоянно какие-то беды. Дошло до того, что у клиента 4 штуки оказались нерабочими. 2 он восстановил перепрошивкой, а 2 отправил на помойку.
За деньги, которые абстрактные эльдорады впаривают вам эти асусы можно было БУ циску взять. Даже если инженера нет - с ней можно разобраться за пару видео-уроков от linkmeup ( не реклама, консультирую неопытных специалистов и даже кое-что на обучение от них беру ) . Да, не факт конечно, что это та самая заветная циска, которая будет работать по 4 года и первый раз зависнет от того, что слой пыли на ней был настолько толст, что она перегрелась ( реальная история ) , но лучше , конечно не лезть в это самим, написать в какой-нибудь профильный чат ( Из головы вспомнить только @ntwrk могу в телеге, но там можно про остальные спросить ), найти человека на шабашку и сказать ему " Купи нормальную железку для офиса на столько-то компьютеров, настрой там вот что это и это работало, и управление по удалёнке настрой, можно даже мониторинг, если умеешь, все пароли и настройки заскриншоть и отправь мне. "
- Кабель , который приходит от провайдера обязательно пометить, да так, чтобы любая продавщица, любая тётя Зина из бухгалтерии поняла, что это провайдерский кабель. Можно на нём стикер повесить, например "%Имя провайдера% и % id канала /№ договора % " будет вообще идеально.
Так же очень, ОЧЕНЬ настоятельно  рекомендую, чтобы этим кабелем можно было дотянуться до компьютера, или на объекте имелся ноутбук. Это важно.
Если провайдер подаёт канал через какое-либо своё устройство - НИКОГДА И НИКУДА ЕГО НЕ ПРЯТАТЬ. Очень неловко получается, когда генеральный директор компании ищет стремянку, чтобы залезть под потолок и перезагрузить устройство, чтобы связь заработала побыстрее. Нет, он конечно не обязан это делать, но ждать пока техник доедет через московские пробки - ему тоже не очень хочется. Так что устройство должно быть на виду, и его тоже желательно промаркировать так, чтобы сотрудникам было понятно. Можете даже провайдеру сообщить, чтобы добавил заметку о расположении, чтобы потом можно было сотрудников ориентировать.
-Теперь немножечко лайфхаков для ИТ-специалистов, которыми, впрочем, может воспользовать любой более-менее грамотный сотрудник компании или просто скопипастить в письмо.
1. То, что должно быть настроено на роутере (Можно спросить у гугла "Как настроить Х на роутере У).
ОБЯЗАТЕЛЬНО.
- Управление извне по WEB/Telnet/SSH . У некоторых роутеров удобнее WEB, у некоторых - консоль. Но даже если вам понятнее WEB - настройте так же и telnet, может добрый инженер подскажет вам пару команд расширенной диагностики. !!!Обязательно смените дефолтный пароль от управления на тот, который будет известен только вам и директору!!!
- Роутер должен быть открыт на ICMP-запросы, т.е. - на ping. Если боитесь DDoS-атак - открывайте перед сдачей проблемы.  Это поможет в диагностике проблем с низкой скоростью и деградацией канала прям сходу.
- Мониторинг трафика, ОСОБЕННО если в офисе есть компы с Win10 или они могут там появиться. Винда может начать качать обновления когда захочет и таким образом забить вам всю пропускную способность.
- DNS-серверы провайдера. Не поленитесь узнать. Особенно актуально с буйством роскомнадзора. РКН блокирует сеть, на которой живёт, например не только телеграм, но и какой-то обычный ресурс. Обычный ресурс меняет сеть, но ваши DNS мухосрань-телекома ещё не обновили информацию, вот у вас и не работает. Если провайдер маленький , например дочерний какого-то большого - попробуйте использовать сервера большого. Не работает - сервера гугла.
ЖЕЛАТЕЛЬНО
- Ограничение скорости на каждый интерфейс, к которому подключаются конечные потребители ( компьютеры сотрудников) . Допустим у вас 10 мбит и 4 компьютера от роутера, ну и ещё WiFi для костей. На WiFi выделяете 2 мбита, а на каждый порт - по 5. Таким образом у вас не получится, что сотрудник скачивая тяжёлый документ парализовал работу офиса ( но два могут, в таком случае можно снизить с 5 до 3 ) , или что гость пришёл с буком на Win10 и забил канал обновлениями.
- Если в сети есть коммутатор, и он поддерживает управление - настройте его. Для этого на роутере и на коммутаторе создаются интерфейсы в отдельном vlan с отдельной приватной сетью. Таким образом, если на каких-то компьютерах интернет работает, а на каких-то нет ( С чем провайдер вам помочь не сможет и не обязан ) - вы сможете не выезжая на объект всё проверить. Все явки , пароли и настройки подробно задокументируйте и оставьте директору, вы ведь не хотите, чтобы он донимал вас в отпуске, или после того, как вы уволились?
- Резервный канал через 3G/LTE . Только для опытных специалистов. С балансировкой маршрутов между основой и резервом могут возникнуть проблемы, часто встречается на MikroTik у рукожопых админов.
2. Интернет сломался, я сижу один на точке, не знаю что делать, с компьютером на ВЫ, какие там роутеры?!
2.1 Перезагрузка оборудования. Начинать с оборудования провайдера, или с оборудования, в которое приходит кабель провайдера. Если провайдер использует DSL-модемы ( дешёво, быстро, далеко. Отличительная черта таких устройств - индикатор DSL/SHDSL/VDSL/ADSL) для подачи канала - то перезагрузка производится следующим образом:
-Отключить питание на устройстве ( обычно это чёрный кабель)
- Вынуть и вставить плотно каждый кабель ПО ОЧЕРЕДИ В ТОТ ЖЕ РАЗЪЁМ, ГДЕ БЫЛО. Один из них - это DSL-линия, порт аналогово-цифровой и частенько зависает он сам. Обычная перезагрузка по питанию может не помочь. В принципе при любой технологии лишним не будет.
"Но я не знаю, я не умею!" - Тётя Зина из бухгалтерии умеет, и ты сумеешь, просто сделай как я написал в ТОЧНОСТИ. Ничего не меняя местами. Нет, током не ударит. Как минимум не насмерть, и даже не больно.
Всё это проделать со всем оборудованием, которое включено после главного.
Если не заработало - пишем/звоним админу. Лучше написать по почте админу и сопроводить звонком.
Что Я - не технический специалист должен  написать своему техническому специалисту?
- Описать что не работает. (Не открываются страницы , не подключается рабочая программа, не работает терминал) .
- Если у админа вы не единственный клиент , но он всё настроил как написано - IP адрес роутера записан в договоре с провайдером и в документации , которую оставил админ, можете его ему написать, чтобы он не искал
- Результаты перезагрузки, что перезагружали и как.
!!!По возможности предоставьте ему диагностику от себя. Нажмите Win + R , далее впишите cmd, нажмите ОК. В черном окне cmd наберите следующие команды: ping 8.8.8.8 ; ping yandex.ru ; tracert yandex.ru ; ipconfig /all  далее нажмите на окне правой кнопкой мыши, нажмите "Пометить", теперь появится возможность выделить все выводы команд, когда они выделены - нажмите ПКМ - и всё, они в буфере, можно вставлять в письмо.
Что должен проверить ваш технический специалист?
- Выяснить, пингуется ли роутер. .
- Если роутер пингуется - значит админ должен на него зайти и произвести проверку. Это:
- Ping и traceroute до внешних ресурсов. (До проблемного ресурса например, тоже)
- Линк в сторону локальной сети офиса.
- ARP - таблица от офисной сети.
- Включен ли DHCP.
- Правильные ли DNS'ы, раздаются ли они по DHCP.
Если на локальной сети порядок, но недоступен ресурс - проверьте IP-адрес в который он резолвится на сайте blocklist.rkn.gov.ru
Если он там - попробуйте пинговать с разными DNS-серверами, возможно сайт уже сменил IP на незаблокированный.
Если роутер не пингуется - специалист должен переслать переписку провайдеру, указав в теме номер договора, адрес, ID канала, и телефон сотрудника на объекте. Провайдер найдет вас и по меньшему объёму  данных, но так будет быстрее.
Какую диагностику запросить?
Да, несомненно, можно ограничиться результатами в переписке которые уже имеются. И опытный инженер поймёт что к чему , но на случай, если вам попадётся балбес, или просто человек, которому плевать - запросите диагностику по пунктам, можете даже выводы команд запросить.
Если сервис совсем не работает:
1. Состояние физики на оборудовании последней мили.  Корректность скорости, дуплекса, наличие ошибок CRC/Коллизий. Результаты диагностики кабеля, если её поддерживает оборудование.
2. Наличие логических настроек на порту оборудования последней мили и транспорте. (L2 связность)  В B2B настройки для каждого клиента чаще всего индивидуальные, и если кто-то неосмотрительно не сохранил конфигурацию, а через год пропало питание на оборудовании - то после его восстановления сервис клиента не восстановится.
3.Наличие L3-связности (ARP-запись при статическом включении или наличие тоннеля при соединениях PPP-типа и прочих)
4. Корректность маршрутизации. (Чаще используется глобальная динамическая маршрутизация, но проблемы с памятью на оборудовании ядра могут вызывать мерзкие сложнодиагностируемые проблемы с доступом к внешним ресурсам для некоторых клиентов.)
5. Корректность скоростных ограничений на канале. (Часто скорость ограничивается на нескольких участках сети, и после заявки на апгрейд например, где-то могут не внести изменения. Или внести, но не сохранить, в результате чего забитый трафиком канал может вести себя как полностью нерабочий.)
6. Статус аппаратных систем оборудования, нагрузка на процессор и память. Из-за перегрева устройства или перегрузок сервисы могут не работать полностью или частично деградировать.
Всё, что выделено жирным можно прям копировать в аварийный запрос, и вас поймут. А если не поймут - отказывайтесь от таких услуг.
Если сервис деградирует - пункты 2 и 3 не обязательны.
Если проблема миновала, но нужны причины сбоя.
1. Аптайм оборудования. Если проблема была кратковременной, то пусть проверяют всю магистраль, а не только последнюю милю. Другие клиенты могли не заметить и не обратиться.
2. Логи с оборудования.  Там можно увидеть , что были проблемы с физикой, перегрузки, атаки, да что угодно практически.
3. Статус и аптайм логического транспорта. Есть много вариантов дотащить трафик от вашего устройства до ядра сети, чаще всего это работает корректно, но лучше лишний раз проверить.
4. По возможности - исторические данные по нагрузке на оборудование. Будь то процессор или трафик. Если вы выбрали негарантированный профиль скорости, а канал проектирован рукозадыми менеджерами - вполне вероятно, что ваш трафик могли вытеснить соседи с гарантированной скоростью. Но это редкость.
5. Счётчики ошибок на оборудовании доступа. Уборщица прибиралась, расшевелила кабели, потом сделала как было. Если нарушила физику - это может отразиться в виде ошибок.

!!! По всем этим пунктам так же провести проверку на своей сети !!!

ВАЖНЫЕ СОВЕТЫ:
*Если провайдер со своей стороны проблем не нашёл, или нашёл проблемы с вашей стороны ( сказал проверять оборудование) - не бегите сразу покупать новое!
Сначала проверьте канал воткнув кабель от провайдера в компьютер, и настроив подключение на нём. Как настроить - может подсказать админ или провайдер. Если проблема не воспроизводится - доверьте работу с оборудованием специалисту. Купите какую-нибудь гадость для домашнего интернета , а потом жаловаться будете.
*Если ваш админ работает удалённо из другого города - пусть найдёт себе подрядчика по месту. Если вы случайно сбросили свой роутер до заводских настроек - ценник на его командировку выйдет больше, чем на работы подрядчика.
*Выездные специалисты провайдера - работают больше с физикой сети, чем с логикой и действуют под руководством опытных инженеров из штаба. По-хорошему им вообще запрещено законом (юристы не бейте, за что купил за то и продаю) что-то настраивать на вашем оборудовании, так что не нужно их склонять к халтуркам и шабашкам по настройке вашей сети. Скажете потом, что "Это ваши ребята настраивали" - а он по шапке получит. Ну или уволится из компании, а потом поди-разберись, что у вас на сети настроено.
*Нет денег на штатного специалиста - пользуйтесь аутсорсом. В гугле достаточно ввести "ИТ-поддержка %Имя Города% " человек приедет и разберётся. Если не разберётся - позвонит провайдеру по аварийной заявке и они вместе всё сделают. Но если долго возится - можете потом позвонить провайдеру и выяснить, насколько квалифицированный специалист вам попался, чтобы решить, стоит с этой компанией  работать потом или нет.
*Если человек, который ответственен за вашу сеть не знает , что такое ARP, VLAN, DHCP, PING - то снимите с него данный функционал и передайте тому, кто разбирается. Горе-админ сломает вашу сеть быстрее, чем вы произнесёте фразу "Зона ответственности" . Нет, ну серьёзно, программисты 1с, администраторы баз данных и сервис-инженеры по ремонту офисной техники не должны этого знать и не обязаны этим заниматься. Даже не всем сис. админам это нужно знать для выполнения обязанностей.

P.S.
Ещё раз прошу прощения за такую неосиляемую простыню, но нагрузка не всегда позволяет что-то писать. Возможно потом напишу пост для большого бизнеса по диагностике L2 и L3 VPN, VoIP, WiFi HotSpot и прочим сложным вещицам для больших разветвлённых торговых сетей.

История из моей практики.

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

В качестве основного использовалась линия от МТС, а как резервный от Билайн. Приняли решение расширить Билайн и сделать балансировку трафика.

Все, надеюсь, понимают, что тарифы для бизнеса сильно отличаются от тарифов для физиков?

Стал пытаться дозвониться до саппорта. Несколько первых попыток приводили к сбросу после ivr (голосового меню). Через некоторое время всё же удалось дозвониться.

Менеджер выслушал меня, принял заявку на увеличение тарифа и пообещал, что со мной скоро свяжутся. И всё...

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

Никто так и не перезвонил...

Заключили договор с ТТК (который дал тариф ощутимо выгодней, чем у Билайна и МТС), а Билайну направили заявление на расторжение. В этот же день мне перезвонили с тупым вопросом "А почему?"

Ни возражений, ни попыток удержать не последовало...

Я был крайне удивлён поведению манагеров в Новосибирском проводном Билайне...

Немного про МТС

За всё время работы с ТТК ни разу не возникало нештатных ситуаций, а вот МТС выкидывал финты.

Например я ушёл летом на месяц в отпуск. Когда вернулся, то увидел в мониторинге, что на следующий день после моего ухода лёг канал МТС. Совсем.

Спросил коллегу, какого х**, а он - "никто не жаловался". А то что у него "авария" весь месяц в мониторинге висела - не предал значения.

Выяснилось, что глюкнул биллинг МТС и система нас отключила....

Благо лето и нагрузки на сеть не было.

Я опять, как и в статье про DHCP, постараюсь идти от сильного упрощения к менее сильному упрощению. Статья ориентирована на уровень студентов и начинающих админов. Я не буду затрагивать вопросы безопасности или конкретной реализации, но постараюсь затронуть те вопросы, которые «проскакивают», либо вовсе игнорируют популярные статьи типа «что такое DNS».

Часть 1. История.

Наиболее увлекательное художественное описание того, как всё начиналось, доступно в rfc1034.

В давние времена, когда сети были маленькими, а компьютеры большими, кто-то заметил, что, во-первых, IP-адреса запоминать не очень удобно (гораздо удобнее слова, которые имеют смысл), а во-вторых, надо бы как-то обозначать один объект с несколькими сетевыми адресами.

«Давай запишем в текстовый файл соответствия сетевых адресов и понятных человеку имён» - сказал кто-то.

«А давайте!» - ответили остальные.

Сейчас вы можете найти файл «hosts» у себя на компьютере и посмотреть в него – почти так всё и было. Люди запоминали имя, запрашивали по имени ресурс. Система смотрела в файлике соответствие имени и сетевого адреса и возвращала по имени адрес. За файлик назначили ответственного, он вносил туда изменения и раздавал через файлообменник свежую версию всем желающим.

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

«Идите в жопу» - сказал ответственный.

«Вот дерьмо, как же быть?» - подумали остальные.

И придумали DNS – Domain Name System – систему доменных имён. Люди были не дураки. Они подумали: «если мы уж внедряем такую сложную систему, на которую потребуется выделить бабло, давайте запихаем туда всё, связанное с именованием ресурсов!». И запихнули.

Что получилось. Общий смысл остался – по имени возвращается адрес. Теперь доменное имя стало состоять из частей, разделенных точкой (Например, pikabu.ru) и за каждую часть (домен определенного уровня иерархии, уровни нумеруются справа налево) стал отвечать свой сервер имён со своим персональным ответственным (на самом деле, всё немного сложнее, разберем в следующих частях). Система стала распределенной и иерархической. Запрос адреса по имени стало возможным разбить на части, и, пройдясь по цепочке серверов имён, найти нужный с нужным ответом. Каждый ответственный теперь мог менять свой кусочек информации, независимо от остальных. В зависимости от настроек, эта информация становилась доступной для всех через некоторое время. К записи о домене добавили дополнительную информацию: информацию о почтовых серверах, о доступных ресурсах, о псевдонимах, служебную информацию и т.д. Корпорации теперь могли делать так, что изнутри на запрос отвечал один сервер имён, а снаружи компании на тот же самый запрос отвечал другой сервер и возвращал другой адрес.

Сформулируем, зачем нужен DNS:

1) Чтобы при вводе имени сайта, например, pikabu.ru, в браузере, система могла понять, на какой сетевой адрес «стучаться»

2) Чтобы при вводе синонима имени сайта www.pikabu.ru, система могла понять, что это имя всё равно, что pikabu.ru

3) Чтобы когда вы отсылаете письма с яндекса на gmail, сервер яндекса знал, на какой сетевой адрес отправить письмо, то есть, где искать почтовый сервер gmail’a

4) Чтобы в ответ, почтовый сервер gmail мог проверить, что адрес, с которого пришло письмо, принадлежит почтовому серверу яндекса.

5) Чтобы при каких-либо проблемах с данной системой, можно было узнать контакты ответственного лица и связаться с ним

«А давайте будем брать за запись о домене деньги?» - подумал кто-то хваткий. И в чьих-то глазах зажглись зеленые искры в виде долларов. Но это уже совсем другая история.

Часть 2. Домен, зона и другие страшные слова.

Отойдём от абстракций и перейдем к конкретике. Зона – это набор ресурсных записей домена, то есть, фактически – это информация о домене и вся та сопутствующая лабуда, о которой мы говорили в части 1. Причем, заметьте, домен в нашем случае, это не «pikabu», а именно «pikabu.ru», так как, скажем, «pikabu.net» - это уже совсем другой домен. Это как директория «помойка» может лежать у вас как на диске C:\, так и на диске D:\ и это будут две разные директории. Зона может быть текстовым файликом или записью в базе данных сервера имён.

Выглядит, примерно так (мне не жалко):

@ означает подставить имя домена целиком

Ресурсная запись (Resource Record – RR) - собственно, информация о некотором ресурсе- состоит из нескольких полей: Владелец, Тип, Класс, TTL, данные. Владелец – это домен, к которому запись относится. Тип может быть одним из стандартных (например, A, AAAA, MX, NS, SOA, TXT и т.д.). Класс раньше разделял записи для Интернет и для других сетей, сейчас, вроде, используется только IN для Интернет. TTL – время, на которое запись разрешено закэшировать резолверу (рекурсивному кэширующему серверу, см. Часть 3). Ну и данные – собственно нужная информация, формат которой зависит от типа записи.

Запись SOA (Start Of Authority) – это начальная запись зоны и она должна быть обязательно, потому остановимся на ней подробнее. В ней содержится целый ряд полей:

- Первичный (Primary) DNS-сервер для некоторой зоны — DNS-сервер, на котором хранится полная исходная информация об этой зоне.

- e-mail ответственного лица

- serial – серийный номер зоны. Фактически, это номер изменения файла зоны. Если у главного DNS-сервера, отвечающего за зону, есть подчиненные сервера, то они периодически сравнивают номер копии зоны у себя с номером на главном сервере. Если на главном номер больше – подчиненные сервера обновляют у себя зону.

- refresh – это то, как часто подчиненные сервера будут пытаться обновить зону

- retry – это то, как часто подчиненные сервера будут пытаться обновить зону, если в первый раз произошла ошибка (например, главный сервер был недоступен)

- expire – то, сколько времени подчиненный сервер может считать информацию о зоне актуальной, если главный сервер ему так и не ответил

- TTL – мы уже говорили – на сколько можно закэшировать запись.

NS – записи содержат сведения о DNS-серверах, где хранится информация о зоне (их может быть больше одного).

А – запись связывает имя с IPv4 адресом. Кстати, если сделать несколько записей с одним именем, но разными адресами, то в ответах они будут чередоваться (чаще всего по алгоритму round robin) – поэкспериментируйте на pikabu.ru и его трех адресах ;)

MX – записи определяют имена почтовых серверов для данного домена (а чтобы узнать их адреса, на почтовые сервера должны быть А-записи в соответствующем домене). Эти записи примечательны тем, что у них есть приоритет (чем меньше приоритет – тем главнее сервер, равный приоритет – распределение нагрузки).

Чуть позже рассмотрим еще PTR записи. Ну а про остальные, если интересно, можно прочитать в вики.

Часть 3. Как идёт запрос.

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

Вы уже поняли, что в системе есть DNS-сервера – сервера имён, на которых хранятся файлы зон. Есть клиенты, которые пытаются узнать адрес по имени (браузер, в котором мы шароебимся по сайтикам, например).

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

Вспоминаем, что система DNS иерархическая. У этой иерархии есть вершина (или корень) – корневая зона, за которой зарезервировано нулевое имя, и за которую отвечают корневые сервера. Эта зона невидимо присутствует во всех доменных именах - на самом деле, все они заканчивают на точку-ничего (можно посмотреть на первую картинку с файлом зоны и увидеть эти точки). Корневые сервера содержат информацию о доменах первого уровня (ru, com, net и т.д.). Этих серверов всего 13 штук (но физически их гораздо больше – резервирование, распределение нагрузки, всё такое). Почему 13? Так исторически сложилось: тогда максимальное количество данных в пакете было 512 байт и туда влезало только 13 записей. Корневые сервера нерекурсивные и некэширующие, кстати.

И сейчас я кратенько перескажу тот самый комикс. Итак, вы вводите в своем любимом браузере адрес любимого сайта pikabu.ru – что же происходит с точки зрения DNS?

1) Браузер роется у себя в кэше – может, вы недавно уже заходили на пикабу и он это еще помнит. Если нет, идем дальше.

2) Потом браузер обращается с животрепещущим вопросом «где же pikabu.ru?» к операционной системе. Она проверяет в своём кэше (может, вы недавно пинговали пикабу?) и в файлике hosts. Если не нашла, передает вопрос тому серверу, который у вас указан на компьютере в качестве DNS.

3) Этот сервер, обычно, сервер провайдера, кэширующий и рекурсивный. То есть, он вернет вам адрес сайта или ошибку. Сначала он проверяет свой кэш (может, ваш сосед по общаге только что запрашивал пикабу?). А еще смотрит в своих зонах (может, он за пикабу и отвечает?). Если ничего не находит, этот сервер начинает собирать ответ, используя нерекурсивные запросы.

4) Первым делом, запрос отправляется на ближайший корневой сервер (вру, там еще есть манипуляции с кэшем, но мы их опустим - пусть ничего нигде не найдено). Адреса корневых серверов известны и меняются очень редко, так что они просто забиты руками во все DNS-сервера. Корневой сервер отвечает, что он в душе не знает адреса «pikabu.ru», но вот тебе список серверов, отвечающих за «ru». Кстати, возвращает он имена и «приклеенные» ip-адреса, а то вы могли бы зациклится в своих запросах.

Кстати, слышали, что rpin вроде как передает права на управление зоной ru Ростелекому?

5) Ок, наш сервер сохранил инфу в кэше (и теперь за всеми сайтами, заканчивающимися на .ru будет обращаться уже к этим серверам). Берет верхний сервер из списка и спрашивает его, где же «pikabu.ru»? Ему отвечают списком из трех адресов, он возвращает верхний операционной системе. Все счастливы, все прописали себе в кэш, что могли, подключаемся к этому IP-адресу и читаем пикабу.

Часть 4. Обратная зона.

Случается так, что нам нужна обратная процедура: не по имени узнать адрес, а по адресу имя. Такие запросы, в частности, используют почтовые сервера, чтобы бороться со спамом. То есть, приходит нам письмо от vasya@gaza.net, например, с адреса 1.23.45.6. И мы хотим узнать, а правда ли адрес 1.23.45.6 является адресом почтового сервера этого домена. Для этого нам надо получить имя по адресу 1.23.45.6 и сравнить его с MX-записью домена (кто заморачивается почтовиками, почитайте еще про spf обязательно).

Для преобразования ip-адресов в имена существует специальный домен in-addr.arpa и специальная запись типа PTR. Как это выглядит, видно на скриншоте. У пикабу, кстати, какая-то лажа с его гуглопочтой, так что пример на другом домене (надеюсь, они не обидятся). Обратите внимание, что IP-адрес переворачивается (задача для самостоятельного раздумья – вспомнить про адресацию и понять, почему).

Часть 5. Внутренняя зона – что за зверь?

Это немножко вбоквел. Например, вы зарегистрировали домен не для себя, а для компании. В компании решили организовать доменную структуру (AD поднять, например). И для этой доменной структуры у вас появляется внутренняя зона DNS. Зона, причем, может быть та же самая, что и в инете, но к той интернетовской зоне она не будет иметь никакого отношения. У вас появляются контроллеры домена (или иные DNS-сервера – держатели внутренней зоны) в вашей локальной сети. На всех компьютерах вашей организации в качестве DNS-серверов вы указываете контроллеры домена (на которых поднята роль DNS). Во внутренней зоне находятся записи внутренних ресурсов: все компьютере в домене, внутренние web-порталы, и т.д. На DNS-серверах корпорации указаны «Forwarders» - сервера, на которые пойдет запрос, если ответа не найдется во внутренней зоне (это уже сервера провайдера, обычно).

Ну, предположим, что pikabu.ru – большая корпорация, в которой есть доменная структура и вы в этой корпорации работаете. Если вы изнутри этой зоны (сидя на работе) выполните команду «nslookup pikabu.ru», вы получите список внутренних DNS-серверов компании, а на сайт пикабушечки не попадёте. Всё потому, что вам ответит внутренний сервер компании, в котором прописано, что «pikabu.ru – это ж я сам и есть, а еще все мои дублирующие сервера!». А вот если вы выполните эту команду из дома, получите внешние адреса пикабу – потому что вам ответит DNS-сервер хостинг-провайдера.

Теперь, предположим, вы с работы набрали www.pikabu.ru. Допустим, у вас в корпорации нет компа с именем www и внутреннего ресурса такого тоже нет. Корпоративный DNS не найдет у себя в зоне записи www и перенаправит запрос на адрес форварда. Мы помним, что это адрес сервера провайдера. И вот тут ответ будет идентичный, что изнутри, что снаружи корпорации, потому что мы искали во внешней зоне.

И третий вариант, у вас в домене есть компьютер W01-vasya-PC.pikabu.ru. Изнутри компании вам внутренний DNS вернет его внутренний адрес. А вот запрос извне "Где W01-vasya-PC.pikabu.ru?" вернет вам "такого хоста не существует" - потому что DNS хостинг-провайдера, где находится ваша внешняя зона pikabu.ru (и куда в конце-концов дочапает DNS-запрос) понятия не имеет о вашей внутренней зоне.

Часть 6. Интересные факты:

Сейчас для распределения нагрузки на корневые сервера используется anycast – это такая публикация маршрутов в сети (BGP), при которой, вам ответит географически ближайший сервер, а не тот, до которого маршрут по некоторым причинам короче.

Максимальное имя поддомена 63 символа, максимальное общее доменное имя 255 символов.

Обычно, обратную зону надо просить прописывать своего провайдера. Но есть вариант, при котором провайдер делает у себя пару записей, а вы после этого можете менять PTR-запись прям у себя в админке родного DNS от хостинг-провайдера (ну, насколько я поняла). Статья вот.

P.S.: Что-то дофига получилось, мда. Надеюсь, кому-то стало понятнее. Правки по существу приветствуются.

Infinity? А, знаю — редкостное говнище!

(с) Один знакомый программист.

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

Осторожно, ненормативная лексика!

Всё ниженаписанное – исключительно моё субъективное мнение.

Чтоб не начинать с чернухи, кое-какие плюсы всё же есть. На мой взгляд, если вам нужен типовой (совсем типовой) Call-центр в ваш небольшой интернет-магазин для впаривания чего-нибудь, то Инфинити вам в общем-то подойдёт. Одну из типовых конфигураций самую малость подпилят под вас, покажут, где менять файлики с текстом впаривания и на этом всё. Реально, под стандартные задачи есть даже какие-никакие инструкции на сайте, жить можно.

Опять же, Инфинити у нас работает и не так плохо, как может показаться из моего поста. Но подгорает-то не от положительных моментов.

А теперь о том, что мне радикально не понравилось. То есть, о минусах.

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

(мы): Будет работать на слабом интернет-канале?

(Инфинити): Конечно, будет! Если там работает IP-телефония, то будет работать и наш клиент.

(мы): Реально маленький канал, до 1 мегабита. IP-телефония работает без нареканий, даже два телефона одновременно.

(Инфинити): тогда вообще без проблем. Мы же сказали, если IP-телефония работает, то и наш клиент будет.

Итог: враньё. 5 мегабит минимум для какой-никакой нормальной работы. Ну, в три можно попробовать ужаться. Клиент на Чукотке (или на 3g модеме в зоне нелучшего приёма) запускается примерно 1:40м (один час сорок минут). Это просто запуск клиента – он грузит свои модули с сервера, судя по всему. А если запуск оборвался, то заново. Карточка позвонившего грузится от 10 до 40 минут (потому что кэп говорит, что мегабит - это не только для инфити, да и не всегда он доступен целиком). Когда обратили на это внимание поддержки, они сказали что-то типа «ну мы ж не думали, что там реально мегабит». Мы решили отдельно запуском софтофона на месте, а клиент инфинити запускается в терминалке через RemoteApp.

И еще о скорости работы и карточках клиента. У нас в карточку подгружается по номеру телефона инфа о клиенте. Ну там, ФИО, пол, возраст и некоторая сопроводиловка. Всего текста на страничку А4 в худшем случае – ничего экстраординарного, никаких фоток и прочей ереси. Филиалы замучили жалобами на медленную загрузку карточки. Глянули Wireshark’ом. 9 мегабайт! Как можно раздуть кусок текста до 9 мегабайт?! Мы даже спросили, может они скриншоты карточки в HD там гоняют? Специально для нас разработчики оптимизировали передачу информации в карточке клиента (до 5 мегабайт на штуку). Тогда-то у нас и стал клиент сносно работать на канале в 4-5 мегабит. То есть, у вас без оптимизации будет та же лажа. Наших программеров оттаскивали от телефона под вопли «дайте мне 10% от цены поддержки и я научу программировать их сраных программистов!».

Внедрение. Как ни странно, внедрение отработали нормально. То есть, хотелки из ТЗ более-менее учтены, правки оперативно вносились. Минус – гонят быстрее провести обучение админов (у нас входило в стоимость 2, кажется, дня обучения). То есть, система еще на стадии подгона под хотелки, в релиз не запущена, трогать ничего нельзя, а вас уже учат с ней работать. Учат на типовой конфигурации и простых примерах, ваши задачи ни разу не учитывают.

Дальше – полный мрак. Система запускается в работу. Ок, первые пробные запуски нормально. Переходим на Инфинити ииии… Специалист техподдержки с вами ровно до 18:00. Вроде бы и ничего страшного, все мы люди. Но мы помним, что после запуска в реальную работу обязательно вылезут косяки. Кредо Инфинити: «Накатим изменения на живую систему в скрипт, который запускается в ночное время. Проверять, конечно, не будем. Трубку брать тоже, мы же работаем с 10 до 18». То есть вам днём, часто не сообщая об этом, вносят изменения в систему. Ночью у вас работает другая логика (с дежурными операторами и другим автоответчиком, например) и всё в 18:00 ломается. Звонки идут в тишину, «набранный номер не существует», сброс звонка через 15 секунд, звонки Москвы идут на Хабаровск – выбери своё, что называется. А в 18:01 уже никто не возьмет трубку и не заглянет в трекер, будь там хоть какой статус у заявки. Тут вариант только разбираться самим и править их свежие косяки «на коленке». Еще можно попытаться вернуть старую логику и тут мы плавно подходим к следующему минусу.

Отсутствие лога изменений. Даже банальной даты создания/изменения скрипта нет. В принципе, если углубиться, то можно найти скомпилированные скрипты в папке Инфинити и посмотреть дату создания файла. Но в самой системе ничего подобного нет. Мы настойчиво попросили писать в поле комментария строку типа «15.04.2016 14:20, сделано то-то. Вася.».

Итак, вы немного освоились, система перестала отрубаться по 3 раза в неделю, и вы решаетесь внести изменения. Ну, потому что надо же когда-то начинать, вы же платите за поддержку, а не за то, чтобы вам вносили изменения, отличные от ТЗ. Например, вам надо что-то чуток изменить в основном скрипте. Вы копируете последнюю версию, открываете иии… Б@#!!! Ну, вы видели значок Хабра? Где что-то среднее между клубочком и Ктулху? Вот что-то подобное вы и наблюдаете. При попытке разобраться, то есть врубить на компонентах отображение направления движения, всё намертво зависает. Оперативки дохрена, а интерфейс её не хавает. Либо шевелите мышкой, либо на экране бегают пузырики данных. Ау, программеры Инфинити! Меня на втором курсе учили, что отображение данных и обработка нажатий пользователя должна быть в разных потоках, чтоб интерфейс «не вис». Ладно, пофиг. Мне потребовалось примерно 10 рабочих часов, чтоб вынести половину в отдельный скрипт и «причесать» остальной трешак. Почему так много? Так я была разбалована Visual Studio, теперь-то скилл прокачан. Сообщаю, здесь нет копи-паста. Ладно, в соседний скрипт скопировать нельзя, но тут нет копи-пасты даже в рамках одного скрипта. То есть, если вам нужно 20 одинаковых компонентов, которые различаются только одним параметром (из 10), то вам 20 раз надо настроить 10 параметров. Скопировать нельзя. Ага, а исходный код можно посмотреть (есть секретная комбинация: зажать Ctrl и нажать иконку сохранения). Код на плюсах, казалось бы – поправь, вставь, скомпилируй! Хрен там, посмотреть можно, скопировать можно, вставить – нет. «Это слишком сложные компоненты».

Итак, пришло время для серьезных изменений! Вы открываете документацию… стойте, где же она? Наверное, на сайте? Нет, там только вики по «стандартным решениям» — в основном, как звонить и пользоваться клиентом. Ну и немного по основным компонентам в стиле «компонент «поднять трубку» используется для того, чтобы поднять трубку». Наверное, нам забыли выслать документацию. Звоним в поддержку и получаем чудесный ответ: «А она еще не написана, в общем то мы и не собирались.» Короче, мы выцыганили примерное описание БД «на отъебись» - только часть баз и таблиц, которые техподдержке показались наиболее значимыми — и это всё. Ни документации системы в целом, ни нашей модификации – ничего этого нет в природе.

Отлично, вы материтесь каждый день, но стокгольмский сидром берет своё, да и просто приноровились к этой чудо-системе. И тут вам начинают жаловаться на неуловимые глюки. Ну там, отчеты врут или звук пропадает. Вы заводите тикет в поддержке, а в ответ тишина. Ну то есть, он даже не принят в работу. День-два-неделя – ноль реакции. Звоните, а в ответ «решаются более приоритетные задачи». Эмм, заглядываете в договор. За поддержку отвалено более полуляма, хоть и российских, но денег – люди как бы не бесплатно работают. После этапа внедрения техподдержка у вас практически отсутствует. У нас, например, начались (и продолжаются) внезапные падения сервиса. То есть, все клиенты зависают, а звонки идут в тишину. При этом переключения на резервный номер не происходит, потому что звонки-то приземляются. Помогает только физический ребут сервера. Реакция на проблему с уровнем «фатально» была до недели (не решение – просто начало работы с заявкой). На более мелкие – от нескольких дней до трех месяцев (бонус в комментариях). Получите сервис за пол-лимона, называется. Ладно, к их чести, менеджер проблему признал (когда мы отказались платить за следующий год, раньше жалобы не помогали). И нам дали три месяца бесплатной поддержки в компенсацию. Стало намного лучше, реакция день-в-день или на следующий. Но! Опять, черт возьми, их эксперименты на живой системе. «Этот скрипт не должен был его уронить, там ничего такого». Конечно, только после его запуска на полдня лёг сервер совместно с номером 8-800 (потому что, чтоб починить, надо было, чтоб звонки шли – логи отслеживать). Опять спрашиваю, у вас что, мощностей на виртуалку нет? Взяли и протестировали бы. Ну, «всё сложно с этим». Лень, я понимаю (правда понимаю, но вы ж, нехорошие люди, за это деньги берёте!).

Ну и еще немного. Техподдержка работает в Инфинити под админской учеткой (что логично). Но если у вас куплена одна админская учетка – вы идете лесом, одновременно работать нельзя. Мы им предложили – да добавьте нам одну лицензию под своего сотрудника! Куплено 120 лицух по 14к каждая. Когда их тоже заколебало, что я постоянно прошу освободить лицуху, нам милостиво предложили сделать одну из наших лицензий администратором (ну хренли, 580к за поддержку + 14к, чтобы она могла работать удобненкько и минус лицуха, которая посчитана для оператора).

Первый чувак из техподдержки нам еще врал, что бэкап делается только с полной остановкой сервера и только из web-интерфейса. Хорошо, следующий сознался, что всё это не обязательно.

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

Из более свежего. Присылают тут скрипт перезапуска служб (правда же, если за год не разобрались, почему сервер падает, давайте будем просто регулярно перезапускать службы). Вот как бы вы добавили в батник паузу? SLEEP? TIMEOUT? Не наш метод! «ping -n 1 -w 10000 192.168.254.254 >null» — вот супер-метод с ответов мэил.ру! На вопрос, что это за хрень? Ответ: «Это проверенный временем скрипт, мы рекомендуем использовать именно его». Не, конечно, можно и гландны через жопу удалить, вопрос — надо ли?

Чтобы запилить свой отчет вам понадобятся навыки SQL (немного) и навыки экстрасенса (много). К счастью, у меня был под рукой гуру-SQL’щик и прокаченый скилл чтения мыслей.

Из самого свежего. Из одного скрипта надо запустить скрипт поствызывной обработки (это типа «дайте оценку оператору от хорошо до прекрасно, спасибо, что вы с нами»). И сюрприз – ошибка компиляции, вы пытаетесь привести тип Int64 к Integer. Знаете, в какой переменной приведение? В ID скрипта! То есть (как я предполагаю), сделали сначала Int на ID, замутили вызов функции. Потом подумали через несколько лет, а вдруг Integer не хватит? Давай замутим Int64! А в прототипе функции никто ничего не менял. Хуле тестировать, в самом-то деле. Решение – «скопируйте функционал в наш старый скрипт, там ID нужного типа, или забейте, авось не выйдете за диапазон» (второй вариант сработал). Ну, тикет еще в работе, может всё не так, как я додумала, а может всё так, но поправят.

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

Из свежих плюсов: новый специалист поддержки, Андрей, отвечает реально быстро, более-менее по делу и даже обратил внимание на одну неточность у меня в скрипте (эх, была бы документация!) – прогресс налицо. Но остального не отменяет.

Итог.. Да нет итога. Работаем с чем есть, я уже относительно разобралась и ваяю скрипты. Наверное, есть много недокументированных возможностей, которые облегчают работу, но их надо еще найти. Гуру-SQL’щик помог запилить отчеты. Всегда приходил на помощь наш цискарь, чтобы снять с инфинити как можно больше функционала (и помедитировать со мной на логи wireshark с ошибками). В общем, для типовой конфигурации с операторами на жирных интернет-каналах можно. Для специфического чего-нибудь с перспективой допиливания своими силами – не советую.

Чуток ответов на вероятные вопросы:

Почему не запилили свою систему? Надо было относительно срочно (за полгода), а программистов отрывать от дела запретили (на них два крупных внутренних программных продукта, очень специфичных и постоянно меняющихся в связи с изменениями в законодательстве + несколько мелких). Нам дали двух программеров на пару месяцев для интеграции с нашей БД. Надо было не только интеграцию, но и красивую мордаху, красивые отчеты и классический функционал call-центра (статусы, учет рабочего времени, скрипты, карточки клиента – вот это всё).

Почему не спросили про документацию? Спросили. Нам сказали, что она есть. Да, мы лошары и поверили.

Почему столько негатива, не всё ж так плохо? Потому что, про то, как инфинити решил все проблемы и погнал бизнес в гору, можно прочитать на сайте Инфинити.

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

Бонус, напоминаю, в комментариях.