По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье рассматриваются вопросы, которые следует задать системным администраторам, и меры предосторожности, которые они должны предпринять при устранении неполадок.
Как правило, устранение неполадок не рассматривается на каких-либо официальных занятиях, - это все то, что большинство из нас в конечном итоге усваивает на собственном горьком опыте. Как действовать, где искать, как определить первопричину возникших проблем - все это навыки, которые мы обычно развиваем с течением времени.
Жизненный цикл сеанса устранения неполадок обычно включает:
Обнаружение - обнаружение проблемы
Идентификация - понимание того, в чем проблема
Анализ - определение причины проблемы
Исправление - исправление того, что было не так
Профилактика - принятие мер для предотвращения повторения проблемы
Систематический подход к устранению неполадок может помочь быстрее выявить основную причину проблемы, которая нарушает работу сервера или приложения. Вот несколько шагов и вопросы, которые нужно задать себе:
1. Что только что изменилось?
Наиболее частая первая реакция на что-то, что перестает работать - это спросить: «Хорошо, а что изменилось?» Изучение последних изменений - это тоже действие, которое, скорее всего, окупится, если на самом деле какое-то существенное изменение было сделано только что. Ищите файлы, особенно файлы конфигурации, которые могли быть изменены, приложения или пакеты, которые были только что добавлены, службы, которые только что были запущены, и т. д. Не упускайте из виду тот факт, что многие системные проблемы возникают не сразу. Примеры того, что идет не так, не связано с недавним изменением, включают:
Медленно заканчивается место на диске
Можете столкнуться с ошибкой конфигурации, которая раньше просто не активировалась из-за несоблюдения определенных условий
2. Какие ошибки я наблюдаю?
Обратите особое внимание на любые ошибки, которые отображаются на системной консоли или в файлах журнала. Указывают ли эти ошибки на какую-то конкретную причину? Вы видели раньше подобные ошибки? Видите ли вы какие-либо проявление тех же ошибок в старых файлах журнала или в других системах? Что вам говорят поисковые запросы в Интернете? Независимо от того, с какой проблемой вы столкнулись, вы вряд ли будете первым системным администратором, столкнувшимся с ними.
3. Как себя ведет система или сервис?
Возможно, стоит обратить внимание на симптомы проблемы. Система или служба работают медленно или полностью непригодны для использования? Может быть, только некоторые пользователи не могут войти в систему. Может быть, не работают только некоторые функции. Выделение того, что работает, а что нет, может помочь вам сосредоточиться на том, что не так.
4. Чем эта система отличается от той, которая является рабочей?
Если вам повезло, что у вас есть дублирующие системы, и у вас есть шанс сравнить ту, которая не работает, с другой. Возможно, вы сможете определить ключевые различия, которые могут помочь выявить причину.
5. Каковы вероятные точки останова?
Подумайте, как работает приложение или сервис и как/где могут возникнуть проблемы. Полагается ли он на конфигурационный файл? Нужно ли ему общаться с другими серверами? Задействована ли база данных? Записывается ли он в определенные лог-файлы? Включает ли это несколько процессов? Можете ли вы легко определить, все ли необходимые процессы запущены? Если можете, систематически устраняйте потенциальные причины.
6. Какие инструменты для поиска и устранения неисправностей могут быть полезны?
Подумайте об имеющихся у вас инструментах для поиска системных проблем. Некоторые из них могут оказаться полезными:
top - для оценки производительности, включая проблемы с памятью, файлом подкачки и загрузкой
df - для проверки использования диска
find - для поиска файлов, которые были изменены за последний день
tail -f - для просмотра последних записей журнала и наблюдения за тем, появляются ли все еще ошибки
lsof - чтобы определить, какие файлы были открыты конкретным процессом
ping - быстрая проверка сети
ifconfig - проверка сетевых интерфейсов
traceroute - проверка подключений к удаленным системам
netstat - проверка сетевых подключений
nslookup - проверка разрешений хоста
route - проверка таблиц маршрутизации
arp - проверка IP-адреса на записи MAC-адреса в вашем кеше
7. Происходит что-нибудь неприятное?
Не исключайте возможность того, что кто-то вмешивался в вашу систему, хотя большинство хакеров предпочли бы делать свою работу так, чтобы вы ничего не заметили.
8. Что мне НЕ делать?
Не путайте симптомы и причины. Каждый раз, когда вы определяете проблему, спрашивайте себя, почему она существует. Будьте осторожны, чтобы не уничтожить «доказательства», пока вы лихорадочно работаете над тем, чтобы вернуть свою систему в оперативный режим. Скопируйте файлы журнала в другую систему, если вам нужно освободить дисковое пространство, чтобы вернуть систему в рабочее состояние. Затем вы можете изучить их позже, чтобы выяснить, что вызвало проблемы, над решением которых вы работаете.
Если вам нужно восстановить файл конфигурации, сначала сделайте копию файла (например, cp -p config config.save), чтобы вам было легче узнать, как и когда файл был изменен, и что вам нужно сделать, чтобы все заработало. Имейте ввиду, что для поиска решения возникшей проблемы вы, возможно, примените большое количество решений. И в последствии не сможете запомнить, какое из решений устранило проблему.
9. Что мне делать?
Запишите все свои действия. Если вы используете PuTTY для подключения (или какой-либо другой инструмент, позволяющий записывать взаимодействия с вашей системой), включите ведение журнала. Это поможет вам, когда вам нужно будет проанализировать, что произошло и как вы решили проблему. Если у вас достаточно места на диске, вы также можете использовать скрипт для записи сеанса входа в систему (например, сценарий устранения неполадок `date% m% d% y`). Если у вас нет возможности сохранять логи, записывайте все, что вы делали и что видели. Вы можете не вспомнить все это позже, особенно если вы находитесь в состоянии стресса. Вы можете помнить шаги, но не порядок, в котором вы их выполняли.
После устранения проблемы задокументируйте, что произошло. Возможно данная проблема возникнет снова, и вам, возможно, придется объяснить своему руководству или клиентам, что произошло, и как вы собираетесь предотвратить это в будущем. По возможности подумайте, как можно избежать данной проблемы в будущем. Можете ли вы улучшить свои службы мониторинга так, чтобы проблемы с дисковым пространством, памятью и сетью, изменения конфигурации и т. д. были решены задолго до того, как они повлияют на работающие службы?
Интернет может быть опасным. Спросите любого хорошего IT-специалиста, и он вам обязательно расскажет о важности обеспечения безопасности и компактности систем, чтобы можно было гарантировать, что новые системы смогут безопасно предоставлять требуемые услуги. И хотя автоматизация этого процесса имеет большое значение для сокращения времени адаптации, настоящим испытанием для системы является способность предоставлять услуги стабильно и без каких-либо пауз на постоянной основе.
Существуют автоматизированные средства, которые могут гарантировать, то ваши сервисы Windows будут такими же безопасными и будут безотказно работать также, как и в день их установки. Однако, поскольку все организации имеют разные потребности и разные бюджеты, то для них некоторые инструменты могут быть недоступны, например, такие как Microsoft System Center Configuration Manager. Но это не должно мешать IT-отделу использовать свою инфраструктуру для обеспечения правильной работы систем.
Ниже приведены несколько принципов управления, которые можно легко реализовать при любом уровне квалификации и любом бюджете, чтобы помочь вашему IT-отделу контролировать свои серверы Windows и убедиться, что они управляются эффективно и безопасно, а также что они оптимизированы для обеспечения максимально возможной производительности.
Аудит политики авторизации
Все серверы должны быть закрыты для всех локальных и интерактивных входов в систему. Это означает, что никто не должен входить на сервер физически и использовать его, как если бы это был рабочий стол, независимо от его уровня доступа. Такое поведение в какой-то момент в будущем может привести к катастрофе. Помимо контроля интерактивных входов в систему, IT-отдел должен иметь политику аудита и других типов доступа к своим серверам, включая, помимо прочего, доступ к объектам, права доступа и другие изменения, которые могут быть внесены в сервер с авторизаций и без нее.
Централизация журналов событий
Серверы Windows имеет множество возможностей ведения журналов, которые доступны по умолчанию. Существуют настройки, с помощью которых можно расширить или ограничить эти возможности ведения журналов, включая увеличение размеров файлов журналов, независимо от того, перезаписываются ли они или нет, даже в, казалось бы, свойственных для них моментах. Централизация всех этих различных журналов в одном месте упрощает доступ к ним и их просмотр для IT-персонала. Можно воспользоваться каким-либо сервером системных журналов и упростить эти журналы, обозначив категории для определенных записей, например, пометить все неудачные попытки авторизации. Также полезным может быть доступность поиска по журналу и возможность для сервера системного журнала иметь интеграцию с инструментами исправления для устранения любых обнаруженных проблем.
Контрольные и базовые показатели производительности
Мы все знаем, как определить, когда сервер или сервис совсем не работают. Но как ваш IT-отдел определяет, работает ли сервер или сервис должным образом? Вот почему полезно получить контрольные показатели ваших серверов и определить базовые показатели их работы с различными интервалами (пиковые и непиковые). Имея такую информацию, можно определить, как оптимизировать параметры программного и аппаратного обеспечения, как это влияет на работу сервисов в течение дня и какие ресурсы нужно добавить, удалить или просто переместить, чтобы обеспечить минимальный уровень обслуживания. Это также помогает определить вероятное направление атак или индикаторы компрометации при обнаружении аномалий, которые могут негативно отразиться на производительности.
Ограничение удаленного доступа
Как администраторы, все мы любим удаленный доступ, не так ли? Я это знаю, поскольку сам почти каждый день использовал протокол удаленного рабочего стола (RDP – remote desktop protocol) для устранения проблем в удаленных системах на протяжении десятков лет своей карьеры. И несмотря на то, что был пройден долгий путь по усилению безопасности за счет усиленного шифрования, факт остается фактом: RDP (как и любые другие приложения удаленного доступа), если их не контролировать, могут позволить злоумышленникам проникнуть на ваши серверы и, что еще хуже, на сеть компании. К счастью, доступ к серверам можно ограничить несколькими способами, например, настроить правила брандмауэра для ограничения доступа к серверам из удаленных подключений, установить требования для использования VPN-туннелирования для защиты связи между сетевыми ресурсами или настроить проверку подлинности на основе сертификатов с целью проверки того, что подключаемая система – как к, так и от – отвергнута или ей можно доверять.
Настройка сервисов
Прошло уже много времени с тех пор, как большинство ролей и сервисов были включены в Windows Server по умолчанию, независимо от того, нужны они организации или нет. Это, очевидно, представляет собой грубейшую ошибку безопасности и до сих пор остается проблемой, хотя и более контролируемой в современных версиях серверов. Тем не менее, ограничение поверхности атаки ваших серверов служит для устранения потенциальных направлений компрометации, и это хорошо. Оцените потребности вашей среды и зависимостей программного обеспечения и сервисов. Это может помочь разработать план по отключению или удалению ненужных сервисов.
Периодический контроль
Периодический контроль тесно связан с вашей сетью и угрозами безопасности. Вы должны следить за состоянием своего сервера, чтобы выявлять любые потенциальные проблемы до того, как они перерастут в серьезную угрозу для производительности устройств и услуг, которые они предоставляют. Такой контроль помогает IT-специалистам заранее определять, нуждаются ли какие-либо серверы в обновлении или ресурсах, или же отдел должен приобрести дополнительные серверы для добавления в кластер, чтобы, опять же, поддерживать работу сервисов.
Управление Patch-файлами
Эта рекомендация должна быть элементарной для всех, кто занимается IT, независимо от опыта и навыков. Если в этом списке и есть что-то, что нужно всем серверам, так это именно управление patch-файлами, или исправлениями. Настройка процесса обновления операционной системы и программного обеспечения имеет первостепенное значение, от простых обновлений, устраняющих ошибки, до корректирующих исправлений, закрывающих бреши в безопасности. Это на самом деле важно, поскольку в интегрированных средах, где используется несколько продуктов Microsoft, некоторые версии ПО и сервисов просто не будут работать до тех пор, пока базовая ОС Windows Server не будет обновлена до минимального уровня. Так что, имейте это в виду, когда будете планировать цикл тестирования и обновлений.
Технические средства контроля
Независимо от того, внедряете ли вы устройства безопасности, такие как система предотвращения вторжений в сеть, или вашим кластерным серверам нужны балансировщики нагрузки, используйте данные, полученные в ходе мониторинга, и базовые показатели для оценки потребностей различных серверов и предоставляемых ими услуг. Это поможет определить, какие системы требуют дополнительных элементов управления, таких как веб-сервер, на котором будет запущено корпоративное веб-приложение для HR-записи. Установка брандмауэра веб-доступа (WAF – web access firewall) предназначена для выявления известных веб-атак, таких как межсайтовый скриптинг (XSS-атаки) или атаки с использованием структурированного языка запросов (SQL-инъекции) на серверную часть базы данных SQL, которая обеспечивает ее работу.
Блокировка физического доступа
По личному опыту знаю, что большинство организаций, от средних до крупных, осознают, что свои серверы необходимо изолировать из соображений безопасности и ОВК. И это здорово! Однако нехорошо получается, когда небольшие компании просто оставляют свои серверы открытыми вместе с обычными рабочими столами. Это действительно ужасно, потому что в таком случае сервер и связи со сторонними устройствами могут быть подвержены множеству потенциальных атак и угроз. Большая просьба – размещайте серверы в хорошо охраняемых помещениях с достаточной вентиляцией и ограничьте доступ в это помещение, разрешите его только тем, кому это действительно необходимо.
Аварийное восстановление
Резервные копии… резервные копии… резервные копии! Эта тема уже настолько избита, но все же мы здесь. Мы по-прежнему знаем, что некоторые организации не принимают никаких надлежащих шагов для правильного и безопасного резервного копирования своих ценных данных. А когда происходит неизбежное – сервер падает, данные теряются, а помочь некому. Но помочь можно было бы, если бы существовал план аварийного восстановления, который бы определял, какие данные нужно защитить, как, когда и где следует создавать резервные копии, а также документированные шаги по их восстановлению. По сути это очень простой процесс: 3-2-1 – три резервные копии, два отдельных носителя и, по крайней мере, одна копия за пределами рабочего места.
Этот список ни в коем случае не позиционируется как исчерпывающий, и IT-специалисты должны самостоятельно изучить каждый пункт, чтобы определить, какие решения лучше всего подходят для их конкретных потребностей. Помимо этого, крайне желательно, чтобы IT-отдел советовался с высшим руководством по разработке политики проведения регулярных оценок рисков. Это поможет IT-отделу определить, где лучше всего размещать ресурсы (финансовые, технические и аппаратное/программное обеспечение), чтобы они использовались максимально эффективно.
Для осуществления перенаправления вызовов по необходимым правилам прибегают к настройке входящих и исходящих маршрутов. Из названия ясно, что входящие маршруты отвечают за обработку входящих вызовов, а исходящие за обработку звонков в город. В статье расскажем о настройке обоих маршрутов в IP – АТС Elastix.
Настройка входящих маршрутов
Начнем с настройки маршрутизации для приходящих на нашу АТС звонков. Для этого, перейдем в раздел PBX → PBX Configuration → Inbound Routes. Перед нами откроется интерфейс настройки входящего маршрута:
В рядовом случае, маршрутизация осуществляется по параметру DID Number - это номер, который набрал звонящий. Например, у вас есть 2 номера: 74951234567 и 74957654321. Чтобы при звонке на первый номер вызовы уходили на оператора, а при звонке на второй номер на менеджера, нужно создать два отдельных маршрута. Чтобы Elastix смог отличить звонок на первый номер от звонка на второй, необходимо создать маршрут с DID Number 74951234567 с перенаправлением на оператора, и второй маршрут с DID Number 74957654321 с направлением на менеджера. Для того, чтобы входящие заработали, достаточно следующей настройки:
Рассмотрим прочие пункты настройки:
Add Incoming Route
Description - описание для создаваемого маршрута
DID Number - номер DID, который мы обсуждали ранее. Это номер, который набирает звонящий.
CallerID Number - в данном поле можно указать номер звонящего (CallerID). В данном случае маршрут будет проверять два условия: совпадения номера звонящего и набранного номера.
CID Priority Route - если вы хотите исключительно маршрутизировать звонок по номеру звонящего, то поставьте галочку в данном чекбоксе.
Options
Alert Info - если данный маршрут является обязательным (аварийным, например, для службы безопасности), мы можете оснащать заголовки SIP сообщений текстом в поле ALERT_INFO. Большинство устройств, получая текст в данном поле могут изменить сигнал звонка или автоматически ответить на звонок
CID name prefix - в данном поле разрешается подставить префикс для имени в составе Caller ID. Например, префикс Partner: на маршруте преобразует звонок с номера 74951234567 в Partner:74951234567
Music On Hold - музыка на удержании, для вызовов, которые отрабатываются по этому маршруту
Signal RINGING - посылать ли сигнал КПВ (Контроль посылки вызова) до ответа на звонок
Pause Before Answer - временная задержка перед обработкой вызова по правилам этого маршрута
Privacy
Privacy Manager - если вызов пришел без CallerID, то звонящему будет предложено ввести свой номера телефона в течение 3 попыток
Call Recording
Call Recording - записывать ли вызовы на данном маршруте
CID Lookup Source
Source - источник для преобразования номеров в имена. Осуществляется с помощью модуля CallerID Lookup Sources
Fax Detect
Detect Faxes - определять ли факсимильные сигналы на данном маршруте
Language
Language - настройка языка, который функционирует на данном маршруте. Например, маршрут может быть предназначен для звонящих из Германии, Франции или России. Настройка так же влияет на параметр Privacy Manager
Set Destination
Выбрать назначение для звонка из представленных
Настройка исходящих маршрутов
Теперь сделаем настройку маршрутов для исходящих вызовов. Переходим в раздел PBX → PBX Configuration → Outbound Routes:
В разделе рассмотрим краткую настройку модуля. Если вы хотите подробно ознакомиться о всеми опциями настройки, то перейдите по этой ссылке.
Итак, чтобы ваши телефоны смогли звонить в город, необходимо настроить следующие позиции:
Route Name - имя для маршрута
Dial Patterns that will use this Route - шаблон для отправки вызовов по этому маршруту. Если вы хотите отправлять все без разбора вызовы и без преобразования в транк, то в поле match pattern укажите . (точку)
Trunk Sequence for Matched Routes - транк, в который вызов будет отправляться по этому маршруту. Можно указать несколько, и, в случае, если первый транк будет не доступен, то будет использоваться следующий.