Хотелось бы добавить, что подобные кабеля использовались (где то ещё используются) для передачи тональных (разговорных) каналов в системах уплотнения. Например, в ИКМ-15 на 15 разговорных каналов, на расстояния до 20 километров. На всём участке использовались несколько зарытых в землю регенераторов, которые восстанавливали форму сигнала. Питание от 500 В для работы регенераторов подавалось по этим же проводам.
С помощью этих кабелей до сих пор передаётся телеметрия со стартовых столов на Байконуре. Каналы собираются в группы до 120 каналов (ИКМ-120 КАМА) и передаются в Москву в ЦУП полётами. На данный момент работает система в резерве, но её колоссальная надёжность позволяет её эксплуатировать и дальше.
Так что по сути, этот кабель предназначен для передачи сигнала в режиме ПРМ/ПРД (приём передача) + дистанционное питание.
Контролировать напряжение необходимо на всех клеммах насоса после контактора. После контактора КМ1. При неисправности контактов/оптоключей контактора весь описанный контроль теряет смысл. У нас на производстве устанавливают дополнительно обыкновенное реле напряжения непосредственно на на сами клеммы насоса.
Закидываем файл docker‑compose.yml в корень проекта FastApi
Если новичок скопирует из текста название файла docker‑compose.yml, то на этом шаге он застрянет надолго, т.к. этот файл на самом деле выглядит как: docker■compose.yml
или просто скайчайте PgAdmin и запустите
Здесь новичка также подстерегает засада в виду отсутствии самой БД
В JSON (оттуда мы тянем информацию) данные записаны у меня так:
{
"student_id": 1,
"first_name": "Иван",
"last_name": "Иванов",
"date_of_birth": "1998-05-15",
"email": "ivan.ivanov@example.com",
"phone_number": "+71234567890",
"address": "г. Москва, ул. Пушкина, д. 10, кв. 5",
"enrollment_year": 2017,
"major": "Информатика",
"course": 3,
"special_notes": "Без особых примет"
}
Нет, не так. "phone_number": "+71234567890" -- > "+7 (123) 456-7890" Этот файл создавался в первом уроке. По итогу, в этом уроке ничего не работает, если не сообразишь.
обыкновенные радиаторы с кулерами от процессоров, выбрал радиаторы с медной «жопкой». Знакомый отремонтировал советский автохолодильник, там я и подглядел как устроено, так же использовался элемент Пельтье.
Собственно и энергию добывать пробовал от костра, правда помощней элемент был, нормально понемногу заряжал смартфон. Прожил, правда, недолго, рассыпался.
Из этих модулей надо не электричество извлекать, а холодильники делать, собственно, для этого конкретно рассматриваемый модуль и предусмотрен.
Из пары подобных я сделал очень практичный автохолодильник.
Ростелеком использует в базе «Стандарт» приставку класса MAG-250 (зависит от региона, где-то в глубинке могут впарить и что-то более древнее, и есть еще нечто под названием SmartLabs SML482), на процессоре STi7105 с 256 МБ оперативной памяти и полугиговым флешем.
Взято в вашего сайта.
Упомянутые приставки стоят гораздо дешевле, умеют гораздо больше, со сторонним ПО умеют всё, например, прошивка DNK (гуглится). Интерфейс можно хоть самому рисовать, пульты можно привязать ЛЮБЫЕ, кнопки назначить — какие хочешь.
Использование архивов Ростелекома, заказ видео, просмотр ВСЕХ каналов от РТ, в том числе шифрованных, DLNA, клиент торрент, просмотр IP камер, установленных дом, Однокласники, VK и всё остальное…
У вас так сможет? Нет. Так что «нечто» уделывают ваше китайское произведение на раз по всем фронтам.
Класс А как то по быстрому и однобоко описали…
Мой первый усилитель был из набора, которые при СССР активно продавали. Там усилитель работал в режиме А, он был двухтактный — это нужно было обязательно упомянуть в статье. А то режим В — двухтактный, а режим А как то не уточнили. Ток покоя выходного каскада был пол Ампера! Я всё тогда голову ломал зачем такой перерасход энергии.
Режим А — самый неэкономичный, но, в случае транзисторной схемотехнике, — самый ближайший к «тёплому ламповому». Потому что лампы в этом режиме и работают. Это тоже надо было упомянуть.
Регистрируются да, но пути их прохождения далее могут отличаться. На данный момент у нас есть необработанные заявки за Апрель, Май. Ветки, столб покосился и т.п., но есть и жалобы на нестабильный интернет. Сроки — не определены. Все эти заявки приходят как раз «по другим каналам». Так что Вы не совсем в курсе дел.
От момента звонка оператору до закрытия заявки время нормировано — 1 сутки для города категории К3. Этот норматив влияет на 40% KPI (40% — за повторную заявку в течении 30 дней, 40% — время устранения повреждения, 20% инсталляция окно — в окно).
Мониторинговая система «Сова» при массовых повреждениях «замораживает» время прохождения заявки. Система полностью автоматическая, никак на неё повлиять нельзя (раньше можно было сгенирировать проблему, если по времени не успеваешь).
Все заявки, которые приходят через «омни-фигомни» чаты, фейсбуки и прочее, — попадают в ад CRM. Время их устранения не нормировано. Руководитель участка просматривает их когда появляется лишняя минутка. Порой и забывают про них. Так что весь сервис HELP/SERVICE DESK раздроблен и до сих пор не оптимизирован. Хотите решить проблему быстро — только звонок. После вашего звонка часики начинают тикать, и все начинают суетится, ибо 40% премии от этого зависит.
Думаю, моя информация окажется кому то полезной.
С ситуацией знаком по работе. Как и у мобильных операторов, у Ростелекома на стационарные телефоны так же есть услуга АнтиАОН. Эта услуга доступна на современных АТС типа Si-2000/3000. В этом случае в личном кабинете будет как у автора «8663ПУСТОЙ», но в тарификационном файле на самой АТС будет отображён полный номер. Есть категории абонентов, когда и в тарификационном файле будет — 8663ПУСТОЙ, но в СОРМ этот номер будет зафиксирован полностью. При оперативных разыскных мероприятиях, например, тот кому звонят подаст заявление в полицию, и, что то серьёзное подтвердится — делается запрос из полиции и производится выгрузка тарификационного файла АТС, если там номер скрыт, то в дело вступает ФСБ… но об этом практически уже никто не узнает.
Так же бывают варианты, когда просто происходит сбой на АТС или в сигнализации ОКС-7, — тогда так же номер звонившего повреждён. Например, у нас на 1000 входящих 1-3 номеров не определены по техническим причинам, их нет даже в файле СОРМ. На сети много старых АТС, координатных, так, если в блоке БП-500 (один из блоков АОН) отвалится маленький диодик, то номер окажется повреждён.
А как бы с Вашей точки зрения выглядело бы продвижение инцидента от 1 до 3 уровня?
«Ну когда попроще, то второй, а если псложнее, то третий!..»
Попроще/посложней в моём понимании — это зона компетенций. Я бы не сказал, что 1 уровень простой, ведь на этом уровне закрывается около 50% инцидентов (оплата, просьба перегрузить и т.п.), 2 уровень работает с железом и имеет информацию по массовым авариям (впрочем информация о массовых авариях имеется и у 1 уровня, но они работают на всю Россию и требуется уточнение на 2 ой линии), 2 уровень может войти в оборудование оператора и клиентского, пообщаться с клиентом и закрыть инцидент. Ну, и 3 уровень, это когда требуется личное присутствие сотрудника оператора у абонента. Все уровни географически расположены в разных не то чтобы городах — регионах. По другому никак.
Свой пример я привёл исходя «Процедуры по обработке технических претензий клиентов» в Ростелекоме. Внимательно изучив Ваши статьи я ещё больше стал недопонимать термин «эскалация», применяя новые знания к существующей Процедуре, которую мы используем каждый день.
Инцидент приходит на 1 ЛТП (линия техподдержки), оператор по заранее разработанной шпаргалке анализирует претензию и передаёт на 2 ЛТП (дословно в Процедуре — «Эскалация проблемы на 2 ЛТП») или, «Запрос коммерческой эскалации»
До 3 ЛТП доходит очень много инцидентов. Например, у абонента оборван провод и он самостоятельно не может это исправить. Понятно, что этот инцидент может урегулировать только 3ЛТП. Время жизни инцидента устанавливается SLA и равен, к примеру, 24 часа от время поступления заявки до её закрытия. Т.е. эскалация — в данном контексте подразумевает передачу инцидента в следующую зону ответственности согласно таблице (по сути с 1-ой ЛТП на 2- ую и далее 3 ЛТП).
Тем не менее, в этой Процедуре написано следующее:
Если Претензия не решена в установленный срок или существует риск нарушения сроков решения в установленные сроки (Приложение 1 настоящей Процедуры), 1ЛТП должен начать процедуру эскалации. В некоторых случаях, с целью соблюдения сроков решения Претензии эскалация проводится круглосуточно.
Эскалация проводится путём привлечения руководства к решению Претензии с соблюдением иерархического порядка (маршрута эскалации) согласно эскалационным данным и способом, указанными в Таблице эскалации, которая представлена в Приложении настоящей Процедуры.
1ЛТП может начать эскалацию в любой момент при наличии рисков несоблюдения сроков, установленных в Приложении 1 настоящей Процедуры.
О случаях, когда претензии передавались руководству мне неизвестны, возможно это что то очень глобальное или когда срок рассмотрения претензии перевалил за 50% отведённого времени SLA.
А вот это выдержка из Процедуры:
Эскалация – поэтапное информирование руководства заинтересованных подразделений в случае нарушения сроков решения Претензии.
Вот так всё запутано. Многие же понимают термин Эскалация, как Вы и подметили «свалить проблемы на другой отдел», в случае, если тот отдел на который «свалили» не согласен может вернуть обратно, у нас даже в системе есть галочка «вернуть обратно» :)
Прохождение инцидента от первой линии техподдержки до третьей — В ITIL это называется функциональной эскалацией. По моему, ничего мутного в определении.
Эскалация — это процедура привлечения внимания к отдельному запросу, когда ход работы над запросом чем-то не устраивает
В приведённом мной примере вообще никакого отношения не имеет. Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.
Хотелось бы добавить, что подобные кабеля использовались (где то ещё используются) для передачи тональных (разговорных) каналов в системах уплотнения. Например, в ИКМ-15 на 15 разговорных каналов, на расстояния до 20 километров. На всём участке использовались несколько зарытых в землю регенераторов, которые восстанавливали форму сигнала. Питание от 500 В для работы регенераторов подавалось по этим же проводам.
С помощью этих кабелей до сих пор передаётся телеметрия со стартовых столов на Байконуре. Каналы собираются в группы до 120 каналов (ИКМ-120 КАМА) и передаются в Москву в ЦУП полётами. На данный момент работает система в резерве, но её колоссальная надёжность позволяет её эксплуатировать и дальше.
Так что по сути, этот кабель предназначен для передачи сигнала в режиме ПРМ/ПРД (приём передача) + дистанционное питание.
Нет, всё верно. Нужно config.py в корень проекта поместить ,а не внутри папки app
Контролировать напряжение необходимо на всех клеммах насоса после контактора. После контактора КМ1. При неисправности контактов/оптоключей контактора весь описанный контроль теряет смысл. У нас на производстве устанавливают дополнительно обыкновенное реле напряжения непосредственно на на сами клеммы насоса.
Если новичок скопирует из текста название файла docker‑compose.yml, то на этом шаге он застрянет надолго, т.к. этот файл на самом деле выглядит как: docker■compose.yml
Здесь новичка также подстерегает засада в виду отсутствии самой БД
Нет, не так. "phone_number": "+71234567890" -- >
"+7 (123) 456-7890" Этот файл создавался в первом уроке. По итогу, в этом уроке ничего не работает, если не сообразишь.чтобы сделать бекап с 1 000 коммутаторов по расписанию и сохранить в определённое место.
Собственно и энергию добывать пробовал от костра, правда помощней элемент был, нормально понемногу заряжал смартфон. Прожил, правда, недолго, рассыпался.
Из пары подобных я сделал очень практичный автохолодильник.
Взято в вашего сайта.
Упомянутые приставки стоят гораздо дешевле, умеют гораздо больше, со сторонним ПО умеют всё, например, прошивка DNK (гуглится). Интерфейс можно хоть самому рисовать, пульты можно привязать ЛЮБЫЕ, кнопки назначить — какие хочешь.
Использование архивов Ростелекома, заказ видео, просмотр ВСЕХ каналов от РТ, в том числе шифрованных, DLNA, клиент торрент, просмотр IP камер, установленных дом, Однокласники, VK и всё остальное…
У вас так сможет? Нет. Так что «нечто» уделывают
вашекитайское произведение на раз по всем фронтам.Мой первый усилитель был из набора, которые при СССР активно продавали. Там усилитель работал в режиме А, он был двухтактный — это нужно было обязательно упомянуть в статье. А то режим В — двухтактный, а режим А как то не уточнили. Ток покоя выходного каскада был пол Ампера! Я всё тогда голову ломал зачем такой перерасход энергии.
Режим А — самый неэкономичный, но, в случае транзисторной схемотехнике, — самый ближайший к «тёплому ламповому». Потому что лампы в этом режиме и работают. Это тоже надо было упомянуть.
Я бы предложил несколько по другому фразу написать.
Мониторинговая система «Сова» при массовых повреждениях «замораживает» время прохождения заявки. Система полностью автоматическая, никак на неё повлиять нельзя (раньше можно было сгенирировать проблему, если по времени не успеваешь).
Все заявки, которые приходят через «омни-фигомни» чаты, фейсбуки и прочее, — попадают в
адCRM. Время их устранения не нормировано. Руководитель участка просматривает их когда появляется лишняя минутка. Порой и забывают про них. Так что весь сервис HELP/SERVICE DESK раздроблен и до сих пор не оптимизирован. Хотите решить проблему быстро — только звонок. После вашего звонка часики начинают тикать, и все начинают суетится, ибо 40% премии от этого зависит.Думаю, моя информация окажется кому то полезной.
Так же бывают варианты, когда просто происходит сбой на АТС или в сигнализации ОКС-7, — тогда так же номер звонившего повреждён. Например, у нас на 1000 входящих 1-3 номеров не определены по техническим причинам, их нет даже в файле СОРМ. На сети много старых АТС, координатных, так, если в блоке БП-500 (один из блоков АОН) отвалится маленький диодик, то номер окажется повреждён.
Попроще/посложней в моём понимании — это зона компетенций. Я бы не сказал, что 1 уровень простой, ведь на этом уровне закрывается около 50% инцидентов (оплата, просьба перегрузить и т.п.), 2 уровень работает с железом и имеет информацию по массовым авариям (впрочем информация о массовых авариях имеется и у 1 уровня, но они работают на всю Россию и требуется уточнение на 2 ой линии), 2 уровень может войти в оборудование оператора и клиентского, пообщаться с клиентом и закрыть инцидент. Ну, и 3 уровень, это когда требуется личное присутствие сотрудника оператора у абонента. Все уровни географически расположены в разных не то чтобы городах — регионах. По другому никак.
Инцидент приходит на 1 ЛТП (линия техподдержки), оператор по заранее разработанной шпаргалке анализирует претензию и передаёт на 2 ЛТП (дословно в Процедуре — «Эскалация проблемы на 2 ЛТП») или, «Запрос коммерческой эскалации»
До 3 ЛТП доходит очень много инцидентов. Например, у абонента оборван провод и он самостоятельно не может это исправить. Понятно, что этот инцидент может урегулировать только 3ЛТП. Время жизни инцидента устанавливается SLA и равен, к примеру, 24 часа от время поступления заявки до её закрытия. Т.е. эскалация — в данном контексте подразумевает передачу инцидента в следующую зону ответственности согласно таблице (по сути с 1-ой ЛТП на 2- ую и далее 3 ЛТП).
Тем не менее, в этой Процедуре написано следующее:
О случаях, когда претензии передавались руководству мне неизвестны, возможно это что то очень глобальное или когда срок рассмотрения претензии перевалил за 50% отведённого времени SLA.
А вот это выдержка из Процедуры:
Вот так всё запутано. Многие же понимают термин Эскалация, как Вы и подметили «свалить проблемы на другой отдел», в случае, если тот отдел на который «свалили» не согласен может вернуть обратно, у нас даже в системе есть галочка «вернуть обратно» :)
В приведённом мной примере вообще никакого отношения не имеет. Никто не привлекает ничьего внимания к запросу, в своей зоне ответственности/компетенции не решили — на следующий уровень передаётся. Каким образом запрос может устраивать или нет? С ним нужно работать.